Git LFS vs. Standard Git: Leistung für große Assets

Git LFS vs. Standard Git wird zu einer echten Frage, wenn Ihr Repository große binäre Assets mit sich führt. Quellcode lässt sich normalerweise gut komprimieren und diffen, aber Videos, Designdateien, Spieltexturen, Modelldateien und große Datensätze können Klone verlangsamen und die Historie schwer bereinigen.

Git Large File Storage, meist Git LFS genannt, hält das normale Git-Repository leichter, indem es ausgewählte Dateien durch kleine Pointer-Dateien ersetzt und den eigentlichen Inhalt in einem LFS-Objektspeicher ablegt. Dieser Kompromiss hilft vielen Teams, ist aber kein Wundermittel. Sie müssen immer noch die richtigen Dateien auswählen, die Tracking-Regeln committen und verstehen, wann LFS Inhalte herunterlädt.

Der Leistungsengpass von Standard Git

Standard Git speichert committete Inhalte in seiner Objektdatenbank und behält genügend Historie, um jede committete Version rekonstruieren zu können. Das funktioniert hervorragend für Textdateien. Es funktioniert schlecht, wenn dieselbe 200 MB große Binärdatei viele Male geändert wird.

Zwei Probleme treten schnell auf:

• Binäre Formate wie JPEG, MP4, ZIP, PSD und kompilierte Artefakte lassen sich oft nicht gut delta-komprimieren.
• Gelöschte Dateien bleiben in der Historie, es sei denn, Sie schreiben die Historie um.
• Neue Klone zahlen für alte Fehler, weil die Git-Historie immer noch diese alten Objekte enthält.
• Repository-Wartungsbefehle haben mehr Daten zu inspizieren und zu packen.

Wenn ein Team beispielsweise jede Sprint eine große exportierte Designdatei committed, entfernt das spätere Löschen der Datei aus dem aktuellen Branch nicht ihre älteren Versionen aus der Historie. Neue Entwickler und CI-Worker laden möglicherweise Daten herunter, die niemand aktiv nutzt.

Einführung in Git Large File Storage (LFS)

Git LFS ist eine Erweiterung, die ausgewählte Dateien außerhalb der normalen Git-Objektdatenbank verwaltet. Ihr Repository behält einen kleinen Text-Pointer. Der eigentliche Dateiinhalt lebt im LFS-Speicher, der von Ihrem Git-Host oder einem anderen LFS-Server bereitgestellt wird.

Das Pointer-System

Ein LFS-Pointer sieht so aus:

version https://git-lfs.github.com/spec/v1
oid sha256:4c2d44962ff3c43734e56598c199589d8995a643...a89c89
size 104857600

Diesen Pointer sieht normales Git. Der Git LFS-Client lädt den echten Dateiinhalt herunter, wenn ein Checkout oder ein expliziter LFS-Befehl ihn benötigt.

Leistungsvergleich: LFS vs. Standard Git

Operation	Standard Git	Git LFS
Initialer Clone	Lädt Git-Historie herunter, die committete große Objekte enthält	Lädt Git-Historie mit Pointer-Dateien herunter; LFS-Inhalt wird je nach Konfiguration möglicherweise beim Checkout heruntergeladen
Repository-Wachstum	Große Binärdateien können die .git-Historie aufblähen	Git-Historie bleibt kleiner, da der Inhalt verfolgter Dateien extern ist
Checkout	Verwendet Objekte, die bereits in der Git-Datenbank sind	Möglicherweise müssen LFS-Objekte für den ausgecheckten Commit abgerufen werden
CI-Jobs	Kann Zeit mit dem Herunterladen historischer Assets verschwenden	Kann LFS-Downloads überspringen oder einschränken, wenn Builds keine Assets benötigen
Bereinigung	Erfordert Umschreiben der Historie, um alte committete Blobs zu entfernen	Erfordert immer noch Sorgfalt, aber neue LFS-verfolgte Versionen blähen die normale Git-Historie nicht auf

Das wichtige Detail ist das Checkout-Verhalten. Ein einfaches git clone mit installiertem Git LFS lädt oft die LFS-Dateien herunter, die für den ausgecheckten Commit benötigt werden. Wenn Sie nur Pointer möchten, verwenden Sie GIT_LFS_SKIP_SMUDGE=1 während des Klonens und holen Sie die Dateien später mit git lfs pull.

Wann Git LFS verwendet werden sollte

Git LFS eignet sich gut für Dateien, die groß, binär und änderbar sind. Häufige Beispiele sind:

• *.psd, *.tiff, *.blend und andere Design- oder 3D-Assets.
• *.mp4, *.mov, *.wav und andere Mediendateien.
• Große Modelldateien, Test-Fixtures oder Datensätze, die das Projekt benötigt.
• Kompilierte Binärdateien nur, wenn das Projekt einen klaren Grund hat, sie zu versionieren.

Legen Sie nicht jede Datei in LFS, nur weil Sie es können. Textdateien, Quellcode, kleine Konfigurationsdateien und Dateien, die Git normal differenzieren soll, sollten in Standard Git bleiben.

Überprüfen Sie die Speicher- und Bandbreitenlimits Ihres Hosting-Anbieters, bevor Sie LFS einführen. GitHub, GitLab, Bitbucket und selbst gehostete Plattformen können sich in Kontingenten, Abrechnung und Aufbewahrungsverhalten unterscheiden.

Implementierung von Git LFS

Installieren Sie den Git LFS-Client und aktivieren Sie dann seine Hooks für Ihren Benutzer:

git lfs install

Verfolgen Sie die Muster, die LFS verwalten soll:

git lfs track "*.psd"
git lfs track "assets/*.mp4"

Diese Befehle erstellen oder aktualisieren .gitattributes. Committen Sie diese Datei zusammen mit den Assets, die sie betrifft:

git add .gitattributes assets/
git commit -m "Design-Assets mit Git LFS verfolgen"
git push

Wenn eine große Datei bereits in der normalen Git-Historie committed wurde, betrifft das Verfolgen mit LFS nur zukünftige Commits. Um die vorhandene Historie zu migrieren, verwenden Sie ein Migrationstool wie git lfs migrate import und koordinieren Sie sorgfältig, da das Umschreiben der Historie Commit-IDs ändert.

Um ohne sofortiges Herunterladen von LFS-Inhalten zu klonen, verwenden Sie:

GIT_LFS_SKIP_SMUDGE=1 git clone [email protected]:example/assets-heavy-repo.git
cd assets-heavy-repo
git lfs pull --include="assets/*.mp4"

Praktische Erkenntnisse

Verwenden Sie Standard Git für Quellcode und kleine Textdateien. Verwenden Sie Git LFS für große binäre Assets, die zum Repository gehören, aber die normale Git-Historie nicht aufblähen sollen.

Fügen Sie für ein Team-Repository frühzeitig LFS-Regeln hinzu, committen Sie .gitattributes, dokumentieren Sie, wie CI mit LFS-Downloads umgeht, und überprüfen Sie die LFS-Limits Ihres Hosts. Das bringt den Leistungsvorteil, ohne Entwickler beim Klonen, Checkout oder Release-Builds zu überraschen.