Flache Klone in Git: Wann und wie man sie verwendet

Flache Klone in Git laden nur einen Teil der Commit-Historie herunter. Sie sind nützlich, wenn ein CI-Job, ein Bereitstellungsschritt oder eine schnelle Inspektion den aktuellen Code benötigt, aber nicht Jahre an Historie.

Sie sind nicht die beste Standardeinstellung für jeden Entwicklerarbeitsplatz. Ein flacher Klon kann Zeit und Speicherplatz sparen, schränkt aber auch historiebasierte Befehle ein, bis Sie weitere Commits abrufen.

Was ist ein flacher Klon?

Ein Standard-Klon lädt genügend Historie für normale Branch-Arbeit, Historie-Inspektion, Checkout alter Tags und Offline-Untersuchung herunter. Ein flacher Klon kürzt diese Historie auf eine von Ihnen gewählte Tiefe.

Zum Beispiel lädt --depth 1 den Spitzen-Commit für den ausgewählten Branch. --depth 50 lädt mehr aktuelle Historie, aber immer noch nicht die vollständige Abstammung.

Vorteile der Verwendung flacher Klone

Der Hauptvorteil sind geringere Übertragungskosten:

Schnellerer erster Checkout für große Repositorys.
Weniger Speichernutzung auf kurzlebigen Build-Agenten.
Geringere Bandbreitennutzung bei langsamen oder volumenbegrenzten Netzwerken.
Weniger Historie, die Git während des initialen Klons verarbeiten muss.

In einer CI-Pipeline, die den aktuellen Commit baut und den Arbeitsbereich verwirft, ist ein flacher Klon oft ein klarer Gewinn.

Nachteile und Einschränkungen flacher Klone

Der Nachteil ist fehlende Historie:

git log stoppt an der flachen Grenze.
git blame kann ältere Änderungen möglicherweise nicht verfolgen.
Alte Tags oder Commits sind möglicherweise nicht verfügbar, bis sie abgerufen werden.
Rebases und Merges können schwieriger sein, wenn Git eine fehlende Merge-Basis benötigt.
Einige Release- oder Audit-Workflows erwarten eine vollständige Historie.

Wenn Ihre Arbeit oft das Debuggen alter Regressionen, die Vorbereitung von Releases oder das Backporten von Änderungen umfasst, beginnen Sie mit einem vollständigen Klon.

Wie man einen flachen Klon erstellt

Verwenden Sie git clone --depth:

git clone --depth <Anzahl> <Repository_URL>

Zum Beispiel, um ein Repository zu klonen und nur die letzten 10 Commits abzurufen:

git clone --depth 10 https://github.com/example/large-repo.git

Für einen Build-Job, der nur den Branch-Spitze benötigt:

git clone --depth 1 https://github.com/example/project.git

Um einen bestimmten Branch zu klonen:

git clone --depth 1 -b develop https://github.com/example/project.git

Sie können auch --single-branch hinzufügen, wenn Sie nur Historie für diesen Branch möchten:

git clone --depth 1 --single-branch --branch develop https://github.com/example/project.git

Verwaltung flacher Klone

Mehr Historie abrufen (Vertiefen des Klons)

Wenn Sie nach dem Klonen mehr Historie benötigen, vertiefen Sie das Repository:

git fetch --deepen=50 origin

Das ruft 50 weitere Commits jenseits der aktuellen flachen Grenze ab.

Sie können auch die gewünschte Gesamttiefe festlegen:

git fetch --depth=100 origin

Der wichtige Punkt: git remote set-depth ist kein gültiger Git-Befehl. Die Tiefe wird durch Klon- und Fetch-Optionen gesteuert.

Tags abrufen

Flache Klone enthalten möglicherweise nicht alle Tags, insbesondere Tags, die auf ältere Commits verweisen. Rufen Sie Tags nur ab, wenn Ihr Workflow sie benötigt:

git fetch --tags origin

Entflachen eines Repositorys

Um einen flachen Klon in einen vollständigen Klon umzuwandeln, rufen Sie den Rest der Historie ab:

git fetch --unshallow origin

Dieser Befehl lädt die verbleibende Historie aus dem entfernten Repository herunter.

Von einem flachen Klon pushen

Das Pushen von einem flachen Klon kann funktionieren, wenn Ihre neuen Commits auf der abgerufenen Remote-Branch-Spitze basieren. Es ist dennoch schlecht für langlaufende Entwicklung geeignet, da fehlende Historie Rebases, Konfliktlösung und Überprüfung erschweren kann.

Wenn Sie auf historiebedingte Push- oder Merge-Probleme stoßen, rufen Sie mehr Historie ab oder entflachen Sie den Klon, bevor Sie fortfahren.

Wann man flache Klone verwenden sollte

Verwenden Sie sie, wenn der Job kurzlebig ist und Historie nicht wichtig ist:

CI/CD-Checkout.
Schreibgeschützte Inspektion.
Temporäre Reproduktionsumgebungen.
Dokumentations-Builds.
Große Repositorys in langsamen Netzwerken.

Wann man keine flachen Klone verwenden sollte

Vermeiden Sie sie, wenn Sie regelmäßig Folgendes benötigen:

Tiefe git log, git blame oder git bisect.
Release-Arbeit, die alte Tags verwendet.
Komplexe Merge- oder Rebase-Arbeit.
Offline-Debugging über Historie hinweg.
Beitrags-Workflows, die einen vollständigen Klon erwarten.

Praktische Erkenntnis

Verwenden Sie git clone --depth 1 für Wegwerf-Jobs, die nur den neuesten Code benötigen. Verwenden Sie einen vollständigen Klon für normale Entwicklung, es sei denn, Sie haben einen klaren Grund dagegen.

Wenn ein flacher Klon Ihnen im Weg steht, vertiefen Sie ihn mit git fetch --deepen=<Anzahl> origin oder konvertieren Sie ihn mit git fetch --unshallow origin. Das ist normalerweise schneller und sicherer, als fehlende Historie-Fehler Befehl für Befehl zu bekämpfen.