Einführung

git clone sieht aus wie eine Operation, setzt sich aber tatsächlich aus mehreren zusammen. Die Schritte zu verstehen hilft beim Troubleshooting partieller Klone, langsamer Klone oder überraschender Voreinstellungen.

Die Sequenz

1. Erstellt das Zielverzeichnis.
2. Führt darin git init aus.
3. Fügt origin als Remote mit der Quell-URL hinzu.
4. Konfiguriert die Standard-Refspec +refs/heads/*:refs/remotes/origin/*.
5. Führt git fetch origin aus, um Objekte und Refs herunterzuladen.
6. Bestimmt den Standard-Branch (das HEAD des Remotes).
7. Erstellt einen lokalen Branch, der ihn trackt.
8. Checkt diesen Branch in den Working Tree aus.

Es beim Geschehen beobachten

GIT_TRACE=1 GIT_TRACE_PACKET=1 git clone https://github.com/example/widget.git 2>&1 | head -50

Sie sehen Capability-Verhandlung, Refs-Advertisement, Want/Have-Verhandlung und Pack-Empfang.

Wire-Protokoll

Modernes Git unterstützt Protokoll v2 (git config protocol.version 2 oder Standard in 2.26+). Der Server kündigt nur die angeforderten Refs an statt der vollständigen Ref-Liste, was die Klonzeiten für Repositories mit vielen Refs dramatisch verbessert.

Varianten

git clone --bare                       # kein Working Tree
git clone --mirror                     # Bare + alle Refs, für Mirroring konfiguriert
git clone --depth 1                    # shallow
git clone --filter=blob:none           # Partial Clone, Blobs erst bei Bedarf
git clone --filter=tree:0              # noch weniger Daten, Trees on-demand
git clone --single-branch              # nur die Historie eines Branches
git clone --branch v1.2.3              # einen bestimmten Branch/Tag auschecken
git clone --recurse-submodules         # Submodules ebenfalls klonen
git clone --no-checkout                # Working Tree nicht befüllen

Partial Clones

Partial Clones (--filter) verschieben Objekt-Downloads, bis Objekte benötigt werden. Sie erfordern Server-Unterstützung (die meisten modernen Hosts haben sie):

git clone --filter=blob:none https://github.com/example/big.git
cd big
git log --oneline                  # billig; nur Commit- und Tree-Objekte gefetcht
git show HEAD:src/main.c           # dies löst einen Blob-Fetch aus

Was wohin geht

Nach einem erfolgreichen Klon:

• .git/objects/pack/: das vom Server empfangene Pack-File.
• .git/refs/remotes/origin/: jeder Server-Branch als Remote-Tracking-Ref.
• .git/HEAD: symbolische Ref auf den neuen lokalen Branch.
• .git/config: [remote "origin"]-Sektion mit URL und Refspec.

Server-seitiges Advertisement

Das Erste, was der Server bei jedem Klon sendet, ist das Ref-Advertisement. Unter Protokoll v0/v1 listet dies jede Ref auf, auch wenn Sie nur eine wollen; bei riesigen Repositories mit Millionen von Refs konnte allein das Advertisement Sekunden dauern. Protokoll v2 ändert dies: Der Client sendet eine ls-refs-Anfrage mit Mustern, und der Server kündigt nur passende Refs an:

git -c protocol.version=2 ls-remote origin 'refs/heads/main'
GIT_TRACE_PACKET=1 git -c protocol.version=2 ls-remote origin 2>&1 | head

Bei alltäglichen Klonen ist die Beschleunigung unsichtbar; bei Hosting-Servern ist sie dramatisch.

Häufige Fehler

Ein riesiges Repository auf einer wackligen Verbindung klonen und von Grund auf neu beginnen; git clone in 2.30+ unterstützt resumable Cloning über das Smart-HTTP-Protokoll, aber nur wenn der Server es unterstützt. Andernfalls zuerst --depth 1, dann später git fetch --unshallow. In ~/Dropbox oder einen anderen Sync-Ordner klonen; der Sync-Client wird mit Git um die Kontrolle über .git/index kämpfen. Ein Repository mit Submodules klonen und --recurse-submodules vergessen, mit leeren Submodule-Verzeichnissen enden. Schließlich: Über HTTPS klonen ohne Credential-Helper und bei jedem Fetch nach Credentials gefragt werden; konfigurieren Sie einen einmal.