Das Repository ist Gigabyte groß und jeder Klon dauert ewig? Meist stecken große Binärdateien in der Historie — Git ist für Code, nicht dafür.
Aufwand:
ca. 40 Min.
Das Symptom
Ein Git-Repository ist über die Zeit gewaltig gewachsen — mehrere Gigabyte —, obwohl
der eigentliche Quellcode nur einen Bruchteil davon ausmacht. Ein frischer Klon
dauert quälend lange, Aktionen fühlen sich zäh an, und der Speicherplatz füllt sich
bei jedem, der das Projekt auscheckt.
Die „Layer 8“-Wahrheit
Git ist ein Meisterwerk für eine ganz bestimmte Aufgabe: die Verwaltung von Text.
Weil es bei Code nur die Unterschiede von Version zu Version speichert, bleibt die
komplette Historie eines großen Projekts erstaunlich klein. Diese Stärke kippt
jedoch bei großen Binärdateien ins Gegenteil. Ein Video, ein hochauflösendes Bild,
ein gebautes Archiv oder eine Datenbankdatei lässt sich nicht als Summe kleiner
Änderungen ablegen — Git speichert bei jeder Änderung praktisch die ganze Datei neu.
Ein einziger großer Anhang, ein paar Dutzend Mal geändert, hinterlässt so ein
Gigabyte-Gebirge in der Historie, das bei jedem Klon mitwandert.
Deshalb ist die Wahrheit unbequem, aber klar: Große Binärdateien gehören nicht
unbedacht in ein Git-Repository. Für die, die wirklich verwaltet werden müssen, gibt
es Git LFS, das sie aus der Historie heraushält und nur einen Verweis hinterlässt;
alles andere — Baugüter, Abhängigkeiten — gehört über die .gitignore gar nicht erst
hinein. Ein aufgeblähtes Repository lässt sich zwar rückwirkend entschlacken, indem
man die Historie umschreibt, doch das ist ein tiefer Eingriff, der alle Mitarbeitenden
trifft und Abstimmung und ein Backup verlangt. Am besten fährt, wer die dicken Brocken
von Anfang an draußen hält.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Die Ursache verstehen
Git speichert die komplette Historie jeder Datei. Bei Textcode ist das effizient, weil nur Änderungen abgelegt werden. Bei großen Binärdateien — Videos, Bildern, gebauten Archiven, Datenbanken — kann Git kaum sparen und legt praktisch jede Version voll ab. So bläht ein einziger großer, oft geänderter Anhang das Repository auf Gigabyte auf.
2.
Die dicken Brocken finden
Zuerst herausfinden, welche Dateien die Historie aufblähen. Werkzeuge analysieren das Repository und zeigen die größten Objekte, auch solche, die längst gelöscht, aber in der Historie noch vorhanden sind. Erst wenn man die Übeltäter kennt, kann man gezielt handeln.
3.
Große Dateien mit Git LFS auslagern
Für künftige große Dateien ist Git LFS (Large File Storage) gedacht: Es legt große Binärdateien außerhalb der eigentlichen Historie ab und speichert im Repository nur einen kleinen Verweis. So bleibt das Repository schlank, obwohl große Dateien verwaltet werden.
4.
Binärdateien gar nicht erst einchecken
Vieles gehört überhaupt nicht ins Repository: gebaute Ergebnisse, Abhängigkeiten, große Datensätze. Solche Pfade in die .gitignore aufnehmen, damit sie nicht versehentlich eingecheckt werden und die Historie belasten.
5.
Die Historie nur mit Bedacht umschreiben
Bereits eingecheckte große Dateien lassen sich rückwirkend aus der ganzen Historie entfernen — das schrumpft das Repository drastisch, schreibt aber die Historie um und betrifft alle Mitarbeitenden. Ein solcher Eingriff will abgestimmt und mit Backup gemacht sein, nicht im Alleingang mitten in der Arbeit.
Häufige Fragen (FAQ)
?Ich habe die große Datei doch gelöscht. Warum ist das Repository trotzdem riesig?
Weil Git nichts vergisst. Jede Version jeder jemals eingecheckten Datei bleibt in der Historie erhalten – das Löschen fügt nur einen weiteren Commit hinzu, der sie entfernt. Die alten Daten liegen weiterhin im Repository und werden bei jedem Klonen mitgeliefert.
?Kann ich große Dateien nachträglich aus der Historie entfernen?
Ja, mit Werkzeugen wie git filter-repo – aber es schreibt die Historie um und ändert damit alle Commit-Kennungen. Jeder, der das Repository geklont hat, muss neu klonen. Auf einem gemeinsam genutzten Repository ist das eine Absprache, kein Alleingang.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Der Diff markiert jede Zeile als geändert, obwohl nur ein Wort angepasst wurde? Zeilenenden. Windows und Unix streiten sich um ein unsichtbares Zeichen.
Git meldet „detached HEAD“? Du stehst nicht auf einem Branch, sondern direkt auf einem Commit — Änderungen hier gehen ohne Gegenmaßnahme leicht verloren.