Shallow Clone
Ein Shallow Clone ist eine abgeschnittene Kopie eines Code-Repositorys, die nur die jüngsten Versionen eines Projekts enthält, nicht die gesamte Änderungsgeschichte. Das spart erheblich Speicherplatz und Ladezeit, schränkt aber bestimmte Operationen ein.
Software-Projekte werden in sogenannten Repositorys verwaltet — das sind geordnete Archive, die nicht nur den aktuellen Stand eines Projekts speichern, sondern jeden einzelnen Schritt, der je daran vorgenommen wurde. Diese vollständige Liste aller Änderungen kann bei großen Projekten Gigabytes umfassen. Ein Shallow Clone ist eine bewusst unvollständige Kopie eines solchen Archivs. Statt der gesamten Geschichte lädt man nur die letzten paar Versionen herunter. Für viele Zwecke reicht das vollständig aus — und es geht erheblich schneller.
Der Unterschied zur vollständigen Kopie
Bei einem normalen Clone lädt man die komplette Geschichte eines Projekts: jeden Zwischenstand, jede Korrektur, jeden Kommentar dazu. Das Versionsverwaltungssystem Git speichert das sehr effizient, aber bei Projekten wie dem Linux-Kernel oder großen KI-Frameworks kommt dennoch schnell ein Gigabyte oder mehr zusammen. Das dauert — und braucht Speicher, der oft einfach nicht gebraucht wird.
Ein Shallow Clone schneidet diese Geschichte an einem bestimmten Punkt ab. Man gibt an, wie viele der letzten Versionen man haben möchte — typischerweise nur die allerjüngste. Alles, was davor liegt, fehlt. Das Ergebnis ist funktional: der aktuelle Code ist vollständig vorhanden und lauffähig. Die Vorgeschichte ist einfach nicht dabei.
Wie Git den Schnitt umsetzt
In Git löst man einen Shallow Clone mit dem Parameter --depth aus, zum Beispiel: git clone --depth 1 [Adresse]. Die Zahl dahinter gibt an, wie viele aufeinanderfolgende Versionen übertragen werden sollen. Bei --depth 1 bekommt man nur den neuesten Stand, also genau einen Schnappschuss.
Intern markiert Git den ältesten übertragenen Punkt als künstliche Grenze. Das Repository weiß, dass dort etwas fehlt. Bestimmte Befehle, die einen Vergleich mit älteren Versionen erfordern — etwa git blame, das zeigt, wer welche Zeile wann geschrieben hat — funktionieren deshalb nur eingeschränkt oder gar nicht. Wer später doch die vollständige Geschichte braucht, kann sie mit git fetch --unshallow nachladen.
Ein häufiger Irrtum: Ein Shallow Clone ist keine beschädigte oder unsichere Kopie. Der Code selbst ist vollständig und integer. Nur die historischen Metadaten fehlen. Wer nur bauen, testen oder lesen will, merkt in der Praxis keinen Unterschied.
Einsatz in automatisierten Build-Systemen
Der wichtigste Einsatzort für Shallow Clones sind CI/CD-Pipelines — das sind automatisierte Systeme, die bei jeder Änderung am Code selbstständig Tests ausführen und neue Versionen bauen. Solche Pipelines starten oft hunderte Male pro Tag. Jedes Mal von Grund auf die gesamte Repository-Geschichte zu laden wäre reine Verschwendung.
Dienste wie GitHub Actions, GitLab CI oder Jenkins verwenden Shallow Clones deshalb standardmäßig. Der Benutzer stellt das oft gar nicht selbst ein — es passiert automatisch im Hintergrund. Ein großes Repository, das als vollständiger Clone zehn Minuten zum Laden bräuchte, ist als Shallow Clone in Sekunden fertig.
Auch beim Einsatz von KI-Modellen aus öffentlichen Repositorys — etwa beim Herunterladen von Modellgewichten oder Trainingscode von Plattformen wie Hugging Face oder GitHub — werden Shallow Clones eingesetzt, um nur den aktuellen Stand zu holen, ohne jahrelange Entwicklungsgeschichte mitzuschleppen.