Git Maintenance: Repository-Gesundheit automatisch pflegen

1. Warum Repositories mit der Zeit langsamer werden

Jeder neue Commit, jeder Fetch und jeder Merge erzeugt neue Git-Objekte, die zunächst lose, also als einzelne Dateien im Objektverzeichnis abgelegt werden. Ohne regelmäßige Konsolidierung wächst die Zahl dieser losen Objekte kontinuierlich, was sowohl den Festplattenplatz als auch die Zeit für Operationen erhöht, die durch die gesamte Objektdatenbank iterieren müssen.

Parallel dazu wird auch der Commit-Graph selbst mit der Zeit teurer zu durchlaufen: Befehle wie git log oder git blame, die Vorfahrenbeziehungen zwischen Commits auswerten müssen, werden in einem großen Repository mit vielen tausend Commits spürbar langsamer, wenn Git bei jeder Anfrage die Beziehungen erneut aus den rohen Commit-Objekten rekonstruieren muss. Diese Verlangsamung fällt anfangs kaum auf, summiert sich aber über Monate hinweg zu einem spürbaren Reibungsverlust im Alltag, gerade wenn viele Entwicklerinnen und Entwickler mehrmals täglich dieselben, inzwischen aufwendigen Abfragen ausführen.

2. Der alte Ansatz: git gc --auto und seine Schwächen

Vor der Einführung von git maintenance war git gc --auto der übliche Mechanismus, der automatisch bei bestimmten Schwellenwerten für lose Objekte oder Pack-Dateien im Hintergrund einer normalen Git-Operation ausgelöst wurde. Das Problem dabei: Der Vorgang lief blockierend im Vordergrund der gerade ausgeführten Operation mit, was bei einem großen Repository zu spürbaren, unvorhersehbaren Wartezeiten mitten in der täglichen Arbeit führen konnte.

Zusätzlich kannte git gc nur eine einzige, grobe Aufgabe, die alles auf einmal erledigte, von der Objekt-Kompaktierung bis zum Aufräumen alter Referenzen. Eine granulare Steuerung, welche Teilaufgabe wie häufig laufen soll, war damit nicht möglich, ebenso wenig ein sauberes Scheduling außerhalb der eigentlichen Git-Nutzung.

3. git maintenance als strukturierter Nachfolger

Seit Git 2.31 steht mit git maintenance ein Befehl zur Verfügung, der Wartungsaufgaben explizit in einzelne, unabhängig voneinander planbare Tasks aufteilt. Statt einer einzigen groben Operation lässt sich jede Teilaufgabe gezielt und mit eigener Frequenz konfigurieren, von stündlich bis wöchentlich, je nachdem wie aktiv ein Repository tatsächlich genutzt wird.

Der Befehl git maintenance run führt dabei entweder alle konfigurierten Tasks oder über --task gezielt eine einzelne Aufgabe aus, was sich sowohl für den interaktiven, manuellen Einsatz als auch für die Einbindung in automatisierte Wartungsfenster eignet.

# Alle konfigurierten Wartungsaufgaben einmalig ausführen
git maintenance run

# Nur eine einzelne Aufgabe gezielt anstossen
git maintenance run --task=gc

4. Die einzelnen Maintenance-Tasks im Überblick

Der Task gc entspricht im Kern dem klassischen Garbage Collection, komprimiert lose Objekte in Pack-Dateien und entfernt nicht mehr erreichbare Objekte nach Ablauf der Aufbewahrungsfrist. Der Task commit-graph aktualisiert eine spezielle Datei, die Vorfahrenbeziehungen zwischen Commits vorab berechnet und dadurch git log sowie ähnliche Befehle erheblich beschleunigt.

Der Task prefetch lädt im Hintergrund neue Objekte von konfigurierten Remotes herunter, ohne lokale Branches zu verändern, sodass ein späteres git fetch oder git pull deutlich schneller abläuft. loose-objects konsolidiert neu entstandene lose Objekte kontinuierlich in kleinere Pack-Dateien, während incremental-repack bestehende Pack-Dateien schrittweise zusammenführt, ohne bei jedem Lauf gleich das komplette Repository neu zu packen.

5. Automatisches Scheduling mit git maintenance start

Der Befehl git maintenance start registriert die konfigurierten Wartungsaufgaben als wiederkehrende Hintergrundjobs im Scheduler des jeweiligen Betriebssystems, unter Linux typischerweise über systemd-Timer oder Cron, unter macOS über launchd und unter Windows über den integrierten Task Scheduler.

Jeder Task erhält dabei eine sinnvolle Standardfrequenz: Der prefetch-Task läuft üblicherweise stündlich, der commit-graph-Task ebenfalls häufig, während der ressourcenintensivere gc-Task nur täglich ausgeführt wird, um die Systemlast während der aktiven Arbeitszeit gering zu halten.

# Wiederkehrende Wartung im Hintergrund einrichten
git maintenance start

# Registrierte Wartung wieder entfernen
git maintenance stop

6. Maintenance je Repository konfigurieren

Einzelne Tasks lassen sich über Konfigurationswerte wie maintenance.gc.enabled gezielt ein oder ausschalten, falls ein bestimmter Task in einem konkreten Repository nicht gewünscht ist. Über maintenance.strategy steht zusätzlich ein vordefiniertes Profil namens incremental zur Verfügung, das eine sinnvolle Kombination aus mehreren Tasks mit abgestuften Frequenzen aktiviert, ohne dass jede Einstellung einzeln vorgenommen werden muss.

Da git maintenance start standardmäßig nur das aktuelle Repository registriert, muss jedes weitere Repository, das automatisch gewartet werden soll, entweder einzeln mit demselben Befehl innerhalb seines eigenen Verzeichnisses aktiviert oder explizit über git config --global --add maintenance.repo <pfad> der globalen Liste hinzugefügt werden.

# Vordefiniertes, abgestuftes Wartungsprofil aktivieren
git config maintenance.strategy incremental

# Ein weiteres Repository der globalen Wartungsliste hinzufuegen
git config --global --add maintenance.repo /pfad/zu/weiterem-repo

7. Nutzen bei großen Monorepos und vielen Mitwirkenden

Bei einem großen Monorepo mit vielen aktiven Mitwirkenden summieren sich häufige kleine Commits und regelmäßige Fetches schnell zu einer erheblichen Zahl loser Objekte, wodurch der Effekt der kontinuierlichen Konsolidierung besonders deutlich spürbar wird. Ein aktueller commit-graph beschleunigt dort insbesondere Befehle wie git log --graph und git blame auf Dateien mit langer Änderungshistorie messbar.

Auch der prefetch-Task zahlt sich in einem solchen Umfeld besonders aus, da neue Objekte bereits im Hintergrund vorliegen, bevor ein Entwickler morgens den ersten git pull des Tages ausführt, wodurch sich die gefühlte Wartezeit am Arbeitsplatz spürbar reduziert. Gerade in Continuous-Integration-Umgebungen, in denen zahlreiche Runner denselben Objektbestand wiederholt klonen oder fetchen, sinkt durch regelmäßige Konsolidierung außerdem die insgesamt übertragene Datenmenge, was sich direkt in kürzeren Pipeline-Laufzeiten niederschlägt.

8. Tasks manuell und gezielt ausführen

Für Server-Repositories, auf denen kein interaktiver Scheduler laufen soll oder darf, lässt sich ein einzelner Task auch gezielt aus einem externen Cronjob oder einem CI-Wartungsfenster heraus aufrufen, ohne dass git maintenance start jemals ausgeführt werden muss.

Das eignet sich besonders für zentrale Bare-Repositories auf einem Git-Server, bei denen die Wartung bewusst in ein festes, planbares Zeitfenster außerhalb der Hauptnutzungszeit gelegt werden soll, statt sich auf die automatische Scheduler-Integration des Betriebssystems zu verlassen.

# Gezielter Aufruf aus einem externen Cronjob heraus
0 3 * * * git -C /srv/git/projekt.git maintenance run --task=gc

9. Status prüfen und Probleme erkennen

Ein einfacher Vorher-Nachher-Vergleich mit git count-objects -v zeigt sowohl die Anzahl loser Objekte als auch die Größe und Anzahl der vorhandenen Pack-Dateien und macht den Effekt der Wartung direkt sichtbar. Bleibt die Zahl loser Objekte trotz aktivierter Wartung dauerhaft hoch, lohnt sich ein Blick in die Logs des jeweiligen Betriebssystem-Schedulers, um zu prüfen, ob die registrierten Jobs tatsächlich ausgeführt werden.

Wird die automatische Wartung nicht mehr benötigt, etwa weil ein Repository archiviert wird, entfernt git maintenance stop alle registrierten Hintergrundjobs sauber wieder aus dem Scheduler des Betriebssystems. Ein regelmäßiger Blick auf diese Kennzahlen lohnt sich vor allem nach größeren organisatorischen Änderungen, etwa wenn ein neues Team-Mitglied dazustößt oder ein bislang selten genutztes Repository plötzlich deutlich aktiver bearbeitet wird, da sich die passende Wartungsfrequenz mit dem tatsächlichen Nutzungsverhalten mitentwickeln sollte.

# Anzahl loser Objekte und Pack-Dateien prüfen
git count-objects -v

10. Zusammenfassung

11. FAQ: Git Maintenance