Git-Garbage-Collection meistern für Spitzenleistung

Die Git-Garbage-Collection verhindert, dass Ihr Repository für immer lose Objekte, veraltete unerreichbare Commits und ineffiziente Packdateien ansammelt. Wenn Ihr Repository langsam ist, zu viel Speicherplatz belegt oder viele Rebases und Branch-Bereinigungen durchlaufen hat, ist git gc eines der ersten Wartungswerkzeuge, das Sie verstehen sollten.

Normalerweise müssen Sie es nicht jeden Tag ausführen. Git führt während normaler Befehle automatische Wartung durch, wenn bestimmte Schwellenwerte erreicht sind. Dennoch hilft es, zu wissen, was es tut, um zwei häufige Fehler zu vermeiden: ein aufgeblähtes Repository monatelang zu ignorieren oder eine aggressive Bereinigung in einem gemeinsamen Repository durchzuführen, ohne die Auswirkungen zu verstehen.

Was die Git-Garbage-Collection tut

Git speichert Daten als Objekte: Commits, Trees, Blobs und Tags. Neue Objekte beginnen möglicherweise als lose Dateien unter .git/objects/. Im Laufe der Zeit kann Git viele Objekte zusammen in kompakte Packdateien packen. Gepackte Objekte nutzen den Speicherplatz effizienter und sind für Git normalerweise schneller zu durchsuchen.

git gc führt mehrere Wartungsaufgaben durch, darunter:

Packen loser Objekte in Packdateien.
Konsolidieren vorhandener Packdateien, wenn sinnvoll.
Entfernen unerreichbarer Objekte, die alt genug zum Löschen sind.
Bereinigen temporärer Dateien, die von unterbrochenen Operationen hinterlassen wurden.
Aktualisieren von Hilfsdaten wie Commit-Graph-Dateien in modernen Git-Setups, wenn konfiguriert.

Unerreichbar bedeutet nicht immer, dass es sofort gelöscht werden kann. Ein Commit kann nach einem Rebase, Amend, Reset oder gelöschtem Branch unerreichbar werden. Git behält normalerweise kürzlich unerreichbare Objekte für eine Gnadenfrist, damit Sie Zeit haben, sie mit git reflog wiederherzustellen.

Überprüfen Sie die Repository-Größe vor der Bereinigung

Beginnen Sie damit, das Repository zu messen, anstatt zu raten:

git count-objects -vH

Nützliche Felder sind count, size, in-pack, packs und size-pack. Eine hohe Anzahl loser Objekte kann alltägliche Git-Operationen verlangsamen. Ein großer size-pack kann einfach bedeuten, dass das Repository viel echte Historie, große Binärdateien oder Anbieter-Assets enthält.

Um die Speichernutzung direkt zu überprüfen, führen Sie aus:

du -sh .git

Wenn .git riesig ist, weil jemand Build-Artefakte oder große Archive committet hat, kann die Garbage-Collection allein das eigentliche Problem nicht lösen. Möglicherweise müssen Sie große Dateien aus zukünftigen Commits entfernen, sie zu Git LFS verschieben oder die Historie mit einem Tool wie git filter-repo umschreiben, nachdem Sie sich mit dem Team abgestimmt haben.

Normale Garbage-Collection ausführen

Für routinemäßige Bereinigungen verwenden Sie:

git gc

Dies ist der sichere Standard. Es überlässt Git die Entscheidung, welche Wartungsarbeiten sinnvoll sind, und respektiert die normalen Löschregeln.

Sie können Git bitten, automatische Wartung nur durchzuführen, wenn die Schwellenwerte dies erfordern:

git gc --auto

Die meisten Benutzer müssen --auto nicht manuell aufrufen, da Git dies bereits im Hintergrund tut. Es ist dennoch nützlich in Skripten, in denen Sie einen kostengünstigen Bereinigungsdurchlauf wünschen, ohne jedes Mal ein vollständiges Repack zu erzwingen.

Wenn Sie alte unerreichbare Objekte mit der standardmäßigen Gnadenfrist entfernen möchten, führen Sie aus:

git gc --prune=now

Verwenden Sie --prune=now vorsichtig. Es kann Wiederherstellungspunkte entfernen, die git reflog sonst möglicherweise finden könnte. Vermeiden Sie es direkt nach einem komplizierten Rebase, Branch-Löschung oder Reset, es sei denn, Sie sind sicher, dass Sie die alten Objekte nicht benötigen.

Seien Sie vorsichtig mit `--aggressive`

git gc --aggressive weist Git an, mehr CPU-Zeit aufzuwenden, um die Objektpackung zu optimieren:

git gc --aggressive

Es ist kein magischer Geschwindigkeitsknopf. In vielen Repositories bringt die zusätzliche Arbeit wenig Nutzen im Vergleich zu normalem git gc, und es kann bei großen Historien lange dauern. Verwenden Sie es nur, wenn Sie ein echtes Repository-Größen- oder Leistungsproblem gemessen haben und sich das Wartungsfenster leisten können.

Für die tägliche Arbeit bevorzugen Sie einfaches git gc. Wenn Ihr Repository regelmäßig aggressive Bereinigung benötigt, liegt das tiefere Problem oft an großen Dateien, generierten Artefakten oder einem Workflow, der viel unerreichbare Historie erzeugt.

Moderne Git-Wartung für laufende Pflege verwenden

Neuere Git-Versionen enthalten git maintenance, das Hintergrundaufgaben wie Prefetching, Commit-Graph-Updates und inkrementelles Repacking je nach Plattform und Konfiguration planen kann.

Um die Wartung einmalig auszuführen:

git maintenance run

Um geplante Wartung für Ihr Benutzerkonto zu aktivieren:

git maintenance start

Überprüfen Sie Ihre Git-Version und lokale Dokumentation, bevor Sie sich in der Automatisierung auf geplante Wartung verlassen, da die genaue Scheduler-Integration je nach Betriebssystem und Git-Build variiert.

Praktischer Bereinigungsworkflow

Ein sicherer Bereinigungsablauf für ein lokales Repository sieht so aus:

git status
git count-objects -vH
git gc
git count-objects -vH

Stellen Sie sicher, dass Ihr Arbeitsverzeichnis vor der Wartung sauber ist. Git kann die Garbage-Collection auch mit lokalen Änderungen ausführen, aber ein sauberes Arbeitsverzeichnis beseitigt Zweifel, falls Sie später Fehler beheben müssen.

Für ein gemeinsames Bare-Repository auf einem Server planen Sie die Wartung während einer ruhigen Periode. Vermeiden Sie schwere Repacks während der Spitzen-CI-Aktivität, da Clone-, Fetch- und Push-Operationen um Festplatten- und CPU-Ressourcen konkurrieren können.

Wann die Garbage-Collection nicht hilft

Die Garbage-Collection kann nicht jedes langsame Git-Repository reparieren. Sie entfernt keine Dateien, die noch in der Historie erreichbar sind. Sie macht ein Monorepo nicht klein, wenn die aktive Historie tatsächlich Jahre großer Assets enthält. Sie repariert kein korruptes Repository von selbst.

Wenn die Leistung nach normaler Bereinigung immer noch schlecht ist, suchen Sie nach diesen Ursachen:

Große Binärdateien, die direkt in Git committet wurden.
Zu viele generierte Dateien, die im Repository verfolgt werden.
Antiviren- oder Dateisystem-Indizierung, die .git bei jedem Vorgang scannt.
Langsamer Netzwerkspeicher, der das Arbeitsverzeichnis hostet.
Sehr große Arbeitsverzeichnisse, bei denen ein spärliches Checkout helfen kann.

Verwenden Sie git gc als Wartung, nicht als Ersatz für Repository-Hygiene. Führen Sie normale Bereinigung durch, wenn die Objektanzahl wächst, vermeiden Sie aggressive Bereinigung, es sei denn, Sie haben einen Bedarf gemessen, und behandeln Sie große verfolgte Artefakte als Workflow-Problem, das an der Quelle behoben werden muss.