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

Git LFS vs. Standard Git: Auswirkungen auf die Leistung bei großen Assets

Git, das grundlegende verteilte Versionskontrollsystem, zeichnet sich besonders durch die Verfolgung von Änderungen in textbasiertem Quellcode aus. Seine Effizienz beruht stark auf inhaltsadressiertem Speicher, der Delta-Kompression nutzt, um kleine, inkrementelle Änderungen über die gesamte Historie hinweg zu verwalten. Dieses Modell stößt jedoch auf erhebliche Leistungshindernisse, wenn es auf große Binärdateien wie Multimedia-Assets, Spieltexturen oder große Datensätze angewendet wird.

Für Projekte, die stark auf nicht-textuelle Daten angewiesen sind, kann die Verwendung von Standard-Git schnell zu einer Aufblähung des Repositories, langsamen Klonzeiten und Ressourcenineffizienz führen. Dieser Artikel bietet einen umfassenden Leistungsvergleich zwischen Standard-Git und Git Large File Storage (LFS), erläutert die Mechanismen beider Ansätze und zeigt auf, wann LFS zum notwendigen Optimierungswerkzeug für die effiziente Verwaltung massiver Assets wird.

Der Leistungsengpass von Standard-Git

Um zu verstehen, warum Git LFS existiert, müssen wir zunächst untersuchen, wie Standard-Git Dateien handhabt und insbesondere, warum dieser Ansatz bei großen Binärdateien versagt.

Inhaltsadressierter Speicher und Historie

Das zentrale Designprinzip von Git besagt, dass jede Version jeder committeten Datei innerhalb der Repository-Historie (im .git-Verzeichnis) gespeichert wird. Wenn ein Repository geklont wird, werden alle historischen Daten – einschließlich jeder Version jeder großen Binärdatei – auf den lokalen Rechner übertragen.

Dieser Ansatz funktioniert aus zwei Hauptgründen schlecht für Binärdateien:

Ineffiziente Delta-Kompression: Binärdateien (wie JPEGs, MP4s oder kompilierte ausführbare Dateien) sind oft bereits komprimiert. Werden nur kleine Änderungen an diesen Dateien vorgenommen, hat Git Mühe, aussagekräftige Deltas zu erzeugen, was oft dazu führt, dass nahezu vollständige Kopien der Datei für jede Revision in der Historie gespeichert werden. Dies beschleunigt das Wachstum der Repository-Größe erheblich.
Obligatorische Historienübertragung: Das Klonen eines Repositories erfordert das Herunterladen der gesamten Historie. Enthält ein Projekt eine 100 MB große Texturdatei, die 50 Mal geändert wurde, muss der initiale Klon mehrere Gigabyte allein für die Historie dieses einen Assets übertragen. Dies beeinträchtigt die Entwicklungsgeschwindigkeit erheblich, insbesondere für neue Mitwirkende oder CI/CD-Systeme.

Ergebnis: Repositories werden massiv, was die Klonzeiten erhöht, Hintergrundwartungsaufgaben (wie Garbage Collection) verlangsamt und übermäßigen lokalen Festplattenspeicher erfordert.

Einführung in Git Large File Storage (LFS)

Git LFS ist eine von GitHub entwickelte (und inzwischen weit verbreitete) Open-Source-Erweiterung, die die Art und Weise ändert, wie Git mit bestimmten Dateitypen umgeht. LFS verlagert die Speicherlast vom zentralen Git-Repository weg, bewahrt die Effizienz von Git für Quellcode und externalisiert gleichzeitig große Binärdateien.

Das Pointer-System

Wenn eine Datei von LFS verfolgt wird, wird der eigentliche binäre Inhalt nicht in der Git-Objektdatenbank gespeichert. Stattdessen speichert LFS eine kleine, standardisierte Text-Pointer-Datei innerhalb des Git-Repositorys. Dieser Pointer verweist auf den Speicherort des eigentlichen binären Inhalts, der auf einem dedizierten LFS-Server gespeichert wird (typischerweise zusammen mit dem Git-Remote, z.B. GitHub, GitLab, Bitbucket).

Eine LFS-Pointer-Datei sieht ähnlich aus:

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

Der Leistungsvorteil: Just-in-Time-Abruf

Der grundlegende Leistungsvorteil von LFS besteht darin, dass Git bei Operationen wie Klonen oder Fetchen nur die kleinen Text-Pointer abruft. Die eigentlichen großen Binärdateien werden nur dann heruntergeladen, wenn sie explizit benötigt werden, typischerweise während eines Checkout-Vorgangs (git checkout oder git lfs pull).

Leistungsvergleich: LFS vs. Standard-Git

Die folgende Tabelle fasst die Leistungsunterschiede bei kritischen Entwicklungsvorgängen im Umgang mit großen Assets zusammen:

Vorgang	Standard-Git Leistung	Git LFS Leistung	Vorteil	Begründung
Initialer Klon	Schlecht/Sehr langsam	Exzellent/Schnell	LFS	Nur kleine Pointer werden heruntergeladen; Binärdateien werden bei Bedarf abgerufen.
Repository-Größe	Sehr groß (aufgebläht)	Klein (schlank)	LFS	Binärdateien werden aus dem `.git`-Verzeichnis ausgelagert.
Checkout/Wechsel	Langsam/Hohe I/O	Schnell	LFS	Ruft nur die spezifisch benötigte Binärversion via HTTP ab.
CI/CD-Build-Zeiten	Langsam (aufgrund massiver Klone)	Schnell	LFS	Deutlich reduzierte Zeit für das Klonen und Abrufen von Abhängigkeiten.
Historische Überprüfung	Erfordert das Herunterladen der gesamten Historie	Nur Pointer (schnell)	LFS	Historie bleibt schlank und verwaltbar.

1. Repository-Aufblähung und Wartung

Standard-Git-Repositories sind bekanntermaßen schwer zu bereinigen, sobald große Assets committet wurden, selbst wenn diese Assets später gelöscht werden (sie bleiben in der Historie erhalten). Dies erfordert komplexe Tools wie git filter-branch oder git filter-repo, um die Historie dauerhaft neu zu schreiben – ein destruktiver und zeitaufwändiger Prozess.

LFS-Auswirkung: Da LFS die großen Dateien auslagert, bleibt die Größe des zentralen Git-Repositorys durchweg klein und einfach zu verwalten, was die für interne Git-Prozesse wie die Garbage Collection (git gc) erforderliche Zeit drastisch reduziert.

2. Bandbreite und Netzwerklatenz

Für verteilte Teams ist die Netzwerkbandbreite ein großes Problem.

Standard-Git: Jeder Benutzer muss die gesamte Repository-Historie ziehen, was bei jedem neuen Klon massive Bandbreitenmengen verbraucht, unabhängig davon, welche Dateien er tatsächlich benötigt.
Git LFS: LFS überträgt nur die spezifischen Binär-Blobs, die dem aktuell ausgecheckten Commit zugeordnet sind. Wenn ein Benutzer nur am neuesten Release-Branch arbeitet, lädt er nur die für diese spezifische Version erforderlichen Binärdateien herunter, was erhebliche Bandbreite spart und den Prozess beschleunigt, insbesondere bei langsameren Verbindungen.

3. Serverlast

Die Verwaltung massiver Repositories belastet den Git-Server stark, insbesondere bei tiefgreifenden Operationen wie dem Abrufen oder Pushen großer Datenmengen. Durch die Verlagerung des Speichermechanismus für große Dateien auf einen separaten, optimierten LFS-Server (der oft einfache HTTP- oder S3-ähnliche Objektspeicherprotokolle verwendet) bleibt der zentrale Git-Server für Standard-Quellcode-Operationen leistungsfähig.

Wann Git LFS verwenden?

Git LFS ist die optimale Wahl für jede Datei, die folgende Kriterien erfüllt:

Große Größe: Im Allgemeinen Dateien über 500 KB bis 1 MB.
Binärformat: Dateien, die sich schlecht komprimieren lassen (z.B. komprimierte Bilder, Videos, Audio).
Häufige Änderungen: Dateien, die oft aktualisiert werden und wiederholte Versionen in der Historie erzeugen (z.B. Game-Assets in der Entwicklung).

Gängige Kandidaten für das LFS-Tracking:

*.psd, *.tiff, *.blend, *.max (Design-/3D-Assets)
*.mp4, *.mov, *.wav (Mediendateien)
*.dll, *.exe, *.jar (Kompilierte Binärdateien, falls committet)
Große *.csv, *.parquet oder Datenbanksnapshots (Data Science)

Git LFS implementieren

Die Implementierung von LFS ist unkompliziert und erfordert die Installation des LFS-Clients sowie die Angabe der Dateimuster, die verfolgt werden sollen.

Schritt 1: LFS installieren und initialisieren

Stellen Sie zunächst sicher, dass der Git LFS Client auf Ihrem Rechner installiert ist. Führen Sie dann den Installationsbefehl einmal in Ihrem Repository aus:

git lfs install

Schritt 2: Dateitypen verfolgen

Verwenden Sie git lfs track, um Git mitzuteilen, welche Dateimuster LFS verwalten soll. Dieser Befehl erstellt oder aktualisiert die .gitattributes-Datei, die für die korrekte Funktion von LFS entscheidend ist.

Beispiel: Verfolgung aller Photoshop-Dateien und großer Videodateien

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

# Review the changes made to .gitattributes
cat .gitattributes
# Output example:
# *.psd filter=lfs diff=lfs merge=lfs -text
# assets/*.mp4 filter=lfs diff=lfs merge=lfs -text

Schritt 3: Committen und Pushen

Entscheidend ist, dass Sie die .gitattributes-Datei zusammen mit den verfolgten Dateien committen müssen. Wenn Sie pushen, überträgt Git die Pointer, und der LFS-Client kümmert sich um das Hochladen der großen Binärdateien in den LFS-Speicher.

git add .gitattributes assets/
git commit -m "Added LFS tracked PSDs and MP4s"
git push

⚠️ Best Practice: .gitattributes zuerst committen

Die .gitattributes-Datei muss vor oder gleichzeitig mit den großen Dateien, die sie verfolgt, committet werden. Wenn Sie die großen Dateien zuerst committen, wird Git sie nativ verfolgen und damit den Zweck von LFS zunichtemachen.

Fazit

Standard-Git ist für seinen vorgesehenen Zweck unschlagbar: Versionskontrolle von Quellcode und kleinen Konfigurationsdateien. Werden jedoch große Binär-Assets eingeführt, verschlechtert sich seine Leistung aufgrund von Repository-Aufblähung und obligatorischen historischen Übertragungen schnell.

Git LFS bietet eine entscheidende Leistungsoptimierung, indem es die Speicherung großer Dateien abstrahiert und so sicherstellt, dass das zentrale Git-Repository leichtgewichtig, schnell zu klonen und einfach zu warten bleibt. Durch die Nutzung des Pointer-Systems und des Just-in-Time-Abrufs verwandelt LFS zuvor träge Operationen in schnelle Prozesse, was es zu einem unverzichtbaren Werkzeug für die Spieleentwicklung, Datenwissenschaft und jedes Projekt macht, das mit umfangreichen, häufig aktualisierten Binär-Assets arbeitet.