Übersicht

git clone [--branch <name>] [--depth <n>] [--recurse-submodules] <url> [directory]

Beschreibung

Der git clone-Befehl kopiert ein bestehendes Repository (typischerweise von einem Remote-Server) in ein neues lokales Verzeichnis. Er führt drei Aktionen durch: Er erstellt ein neues Verzeichnis, führt git init darin aus und holt dann alle Branches und die Historie vom Remote. Nach dem Klonen ist der Remote automatisch als origin konfiguriert, und der Standard-Branch wird in den Working Tree ausgecheckt.

Klonen unterstützt mehrere Protokolle: HTTPS (am üblichsten, am einfachsten mit Credential-Helpern), SSH (bevorzugt für Schreibzugriff mit schlüsselbasierter Authentifizierung) und das ältere git://-Protokoll. Für sehr große Repositories können Partial Clones, Shallow Clones und Sparse Checkouts die übertragene Datenmenge dramatisch reduzieren.

Authentifizierung ist eine der häufigsten Stolperfallen. Mit HTTPS verwendet modernes Git Credential-Helper (Keychain auf macOS, Credential Manager auf Windows, libsecret auf Linux), um Tokens oder Passwörter sicher zu cachen. Mit SSH liefert Ihr lokaler SSH-Agent den Schlüssel — stellen Sie sicher, dass ssh-add ihn geladen hat. Nach dem Klonen bestätigt git config --get remote.origin.url, was tatsächlich konfiguriert wurde. Für Monorepo- oder Supercomputer-große Repositories erlauben Partial Clones (--filter=blob:none) kombiniert mit Sparse Checkout (git sparse-checkout init --cone), nur an einem Ausschnitt des Projekts zu arbeiten und sowohl die Klonzeit als auch den Festplatten-Footprint dramatisch zu reduzieren. CI-Pipelines profitieren weiterhin von --depth=1 und --no-tags, wenn sie keine Historie brauchen.

Im täglichen Einsatz integriert sich git clone eng mit Shell-Aliasen, Editor-Plugins und Continuous Integration. Power-User fügen oft Aliase hinzu, die Flags kombinieren, die sie immer übergeben, oder wickeln den Befehl in Skripte, die Teamkonventionen durchsetzen. Die Ausgabeformatierung kann über Git-Config angepasst werden — Pretty-Formate, Farbschemata und Pager-Verhalten sind alle einstellbar. Wenn etwas schiefgeht, ist der erste Diagnoseschritt üblicherweise, den Befehl erneut mit GIT_TRACE=1 in der Umgebung auszuführen, was die zugrunde liegenden Plumbing-Aufrufe offenlegt. Für ungewöhnliche Situationen öffnet die --help-Ausgabe (git clone --help) die vollständige Manpage mit Details zu jeder Option, einschließlich solcher, die in alltäglichen Workflows selten verwendet werden, aber für Debugging oder Skripting im großen Maßstab essentiell sind.

Zu verstehen, wie git clone mit dem Rest von Gits Datenmodell interagiert — der Objektdatenbank, dem Index, Refs und dem Working Tree — zahlt sich aus. Jeder Befehl operiert auf einer Teilmenge dieser Stücke, und zu wissen, welche er berührt, hilft Ergebnisse vorherzusagen und sich von Fehlern zu erholen. Das Lesen der offiziellen Git-Dokumentation neben praktischer Übung in einem Wegwerf-Repository ist der schnellste Weg, die Nuancen zu verinnerlichen. Die meisten Produktionsprobleme mit Git rühren von einer von drei Ursachen: überraschendem Standardverhalten, partiellen Netzwerkoperationen oder dem Umschreiben bereits geteilter Historie. Ein funktionierendes mentales Modell der Nebenwirkungen von git clone hilft, alle drei zu vermeiden.

Häufige Optionen

Option	Beschreibung
--branch <name> / -b	Checkt den benannten Branch oder Tag statt des Standards aus.
--depth <n>	Erstellt einen Shallow Clone mit gekürzter Historie.
--single-branch	Klont nur die Historie eines einzelnen Branches.
--recurse-submodules	Initialisiert und klont Submodules unmittelbar nach dem Hauptklon.
--filter=blob:none	Erstellt einen Partial Clone ohne Blob-Inhalte (lazy bei Bedarf gefetcht).
--bare	Erstellt einen Bare-Klon ohne Working Tree.
--mirror	Richtet einen Mirror mit allen Refs ein, geeignet für Backups.

Beispiele

git clone https://github.com/user/project.git
    # Standard-Klon über HTTPS

    git clone [email protected]:user/project.git my-fork
    # Klonen via SSH in ein bestimmtes Verzeichnis

    git clone --depth 1 --branch v2.0 https://github.com/user/project.git
    # Shallow Clone eines bestimmten Tags, nützlich für CI

    git clone --filter=blob:none https://github.com/torvalds/linux.git
    # Partial Clone für riesige Repos — Blobs werden bei Bedarf gefetcht

Häufige Fehler

Ein riesiges Repository ohne Filter zu klonen kann Minuten oder Stunden dauern und Gigabyte verbrauchen. Bevorzugen Sie für Erkundung oder CI-Builds --depth 1. Ein weiterer Fehler ist das Klonen über HTTPS, wenn Sie Änderungen pushen wollen — ohne Credential-Setup fragt jeder Push nach einem Passwort. Verwenden Sie SSH oder einen Credential-Helper für Schreibzugriff. Schließlich: Beachten Sie, dass --single-branch-Klone nicht ohne Weiteres auf andere Branches zugreifen können, ohne den Remote neu zu konfigurieren.

Verwandte Befehle

git init, git fetch, git remote, git submodule