Git beschleunigen: Wichtige Techniken zur Leistungsoptimierung

Langsames Git hat normalerweise eine konkrete Ursache: zu viel Historie, zu viele nicht versionierte Dateien, große Binärobjekte, teure Dateisystem-Scans oder Netzwerklatenz. Bevor Sie Git selbst die Schuld geben, prüfen Sie, welcher Vorgang langsam ist und was er zu lesen oder herunterzuladen versucht.

Die Leistungsoptimierung von Git funktioniert am besten, wenn Sie die Lösung auf das Symptom abstimmen. Ein langsamer CI-Klon erfordert eine andere Antwort als ein langsames git status in einem riesigen Arbeitsverzeichnis.

Die Ursachen für langsame Git-Leistung verstehen

Beginnen Sie mit den häufigsten Ursachen:

• Eine lange Historie mit vielen Dateien und Referenzen.
• Große Binärdateien, die direkt in Git committet wurden.
• Build-Ausgaben, Abhängigkeitsordner oder Logs, die unignoriert im Arbeitsverzeichnis liegen.
• Viele veraltete Remote-Tracking-Branches und Tags.
• Langsame Netzwerkverbindungen zum Remote-Repository.
• Alte Git-Versionen, denen neuere Wartungs- und Sparse-Checkout-Verbesserungen fehlen.

Führen Sie den langsamen Befehl mit Bedacht aus. Wenn git clone langsam ist, prüfen Sie die Größe der Historie und die Netzwerkübertragung. Wenn git status langsam ist, prüfen Sie die Größe des Arbeitsverzeichnisses, ignorierte Dateien und das Dateisystemverhalten. Wenn git fetch langsam ist, prüfen Sie Remote-Referenzen, Tags und geänderte Objekte.

Klon- und Fetch-Kosten reduzieren

Für CI, Bereitstellungsjobs und schreibgeschützte Inspektionen benötigen Sie oft nicht die vollständige Historie.

Verwenden Sie einen flachen Klon:

git clone --depth <anzahl> <repository_url>

Um beispielsweise nur die letzten 10 Commits zu klonen:

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

Für CI-Jobs, die nur den aktuellen Commit erstellen, ist --depth 1 oft ausreichend. Für Entwicklerarbeit ist ein vollständiger Klon normalerweise weniger überraschend, da Befehle wie tiefes git log, das Auschecken alter Tags und manche Rebases mehr Historie benötigen.

Wenn Sie bereits einen flachen Klon haben und mehr Historie benötigen, vertiefen Sie ihn:

git fetch --deepen=50 origin

Oder konvertieren Sie ihn in einen vollständigen Klon:

git fetch --unshallow origin

Für partielle Datenanforderungen unterstützen neuere Git-Versionen auch partielle Klonfilter wie --filter=blob:none, aber verwenden Sie diese nur, wenn Ihr Git-Host und Ihr Workflow sie gut unterstützen:

git clone --filter=blob:none https://github.com/beispiel/grosses-repo.git

Große Dateien aus der normalen Git-Historie heraushalten

Große Binärdateien sind einer der schnellsten Wege, Git langsam zu machen. Bilder, Videos, Archive, Design-Dateien und Modelldateien lassen sich oft nicht gut komprimieren oder differenzieren.

Verwenden Sie Git LFS für große Assets, die wirklich zum Repository gehören:

git lfs install
git lfs track "*.psd"
git lfs track "assets/*.mp4"
git add .gitattributes
git commit -m "Große Assets mit Git LFS verfolgen"

Git LFS wirkt sich auf zukünftige Commits aus, nachdem die Tracking-Regeln eingerichtet wurden. Wenn jemand bereits große Dateien in die normale Git-Historie committet hat, reicht es nicht aus, sie aus dem aktuellen Verzeichnisbaum zu entfernen. Möglicherweise ist eine koordinierte Umschreibung der Historie mit einem Tool wie git lfs migrate import oder git filter-repo erforderlich.

Für generierte Build-Artefakte ist die bessere Antwort normalerweise nicht LFS. Committen Sie sie nicht. Fügen Sie sie stattdessen zu .gitignore hinzu:

node_modules/
dist/
coverage/
*.log

Lokale Referenzen und Objekte bereinigen

Veraltete Remote-Tracking-Branches fügen Unordnung hinzu und können Befehle verlangsamen, die Referenzen auflisten oder überprüfen. Entfernen Sie sie während des Fetchens:

git fetch --prune

Löschen Sie lokale Branches, die bereits gemerged und nicht mehr benötigt werden:

git branch --merged
git branch -d alter-feature-branch

Lassen Sie Git die Wartung durchführen:

git maintenance run

Bei älteren Workflows ist git gc immer noch nützlich:

git gc

Vermeiden Sie aggressive Bereinigungsbefehle, es sei denn, Sie wissen, warum Sie sie benötigen. Das Ablaufen von Reflogs kann es beispielsweise erschweren, sich von einem fehlgeschlagenen Reset zu erholen.

git status günstiger machen

git status muss das Arbeitsverzeichnis überprüfen. Wenn Ihr Projektverzeichnis Tausende von generierten oder Abhängigkeitsdateien enthält, kann der Status laut und langsam werden.

Verwenden Sie .gitignore für Dateien, die Git nicht berücksichtigen soll. Wenn eine Datei bereits versioniert ist, verhindert .gitignore nicht, dass Git sie weiterverfolgt; Sie müssen sie zuerst aus dem Index entfernen:

git rm --cached pfad/zu/generierter-datei

Für sehr große Repositorys, in denen Sie nur einen Teil des Verzeichnisbaums benötigen, kann Sparse Checkout helfen:

git sparse-checkout init --cone
git sparse-checkout set services/api docs

Das behält nur ausgewählte Pfade in Ihrem Arbeitsverzeichnis. Es ist in Monorepos nützlich, aber Ihr Team sollte die erwarteten Sparse-Pfade dokumentieren, damit Entwickler keine Dateien übersehen, die sie benötigen.

Fetch von Integration trennen

git pull holt und integriert dann Änderungen mit Merge oder Rebase, abhängig von der Konfiguration. Wenn ein Repository groß ist oder ein Branch abgewichen ist, ist es oft klarer, zuerst zu fetchen:

git fetch origin
git log --oneline HEAD..origin/main
git merge origin/main

Das macht die Netzwerkübertragung an sich nicht kleiner. Es gibt Ihnen Kontrolle, bevor Sie Ihren Arbeitsbranch ändern.

Praktische Erkenntnisse

Verwenden Sie flache Klone für kurzlebige Jobs, Git LFS für große Assets, .gitignore für generierte Dateien, das Entfernen für veraltete Referenzen und Sparse Checkout für große Verzeichnisbäume, in denen Sie nur eine Teilmenge benötigen. Halten Sie Git aktuell, aber verwenden Sie Integritätstools wie git fsck nicht als Leistungsverbesserung, es sei denn, Sie vermuten eine Repository-Beschädigung.

Wenn Git sich langsam anfühlt, notieren Sie den genauen Befehl und wo die Zeit hingeht: Netzwerkübertragung, Objektverarbeitung oder Arbeitsverzeichnis-Scan. Dieses eine Detail weist normalerweise auf die richtige Optimierung hin.