Die Zukunft großer Dateien in Git ist Git selbst

• Das Git-Projekt hat vor Kurzem offiziell begonnen, das Problem der Verwaltung großer Dateien direkt selbst zu lösen
• Git LFS ist eine Behelfslösung, die für Nutzer verschiedene Kosten und Vendor-Lock-in mit sich bringt
• Mit der jüngeren Funktion partial clone kann Git selbst inzwischen den Großteil der Aufgaben von LFS übernehmen
• Künftig wird mit large object promisor zudem eine neue Lösung zur Integration in offizielles Git vorbereitet
• Dadurch zeichnet sich ab, dass die endgültige Lösung für die Verwaltung großer Dateien nicht in externen Erweiterungen, sondern in Git selbst liegen wird

---

Das Problem großer Dateien in Git und der Wandel

• Wenn Git einen größten Erzfeind hat, dann sind es große Dateien
• Große Dateien blähen Git-Repositories auf, verlangsamen git clone und wirken sich auch in den meisten Hosting-Umgebungen negativ aus

Das Erscheinen von Git LFS und seine Grenzen

• 2015 veröffentlichte GitHub Git LFS, um das Problem großer Dateien zu umgehen
• Doch Git LFS selbst bringt zusätzliche Komplexität und Speicherkosten mit sich

• Die Git-Community hat stillschweigend über das Grundproblem großer Dateien nachgedacht, und in den jüngsten offiziellen Releases von Git wurde eine neue Richtung für die Verwaltung großer Dateien ohne LFS aufgezeigt

Was schon heute möglich ist: Git LFS durch partial clone ersetzen

• Das Prinzip von partial clone

  • Git LFS: Große Dateien werden außerhalb des Repositories abgelegt, und für die Arbeit werden nur die benötigten Dateien heruntergeladen
  • Git partial clone (eingeführt 2017):
    • Mit der Option --filter wird geklont, wobei Blobs ab einer gewünschten Größe ausgeschlossen werden
    • Die jeweiligen großen Dateien werden nur bei Bedarf vom Server nachgeladen
      > Mit Partial Clone müssen [große binäre Assets] während Clone und Fetch nicht vorab heruntergeladen werden, wodurch Download-Zeit und Speicherplatzbedarf sinken
      > - Partial Clone Design Notes, git-scm.com

• Gemeinsamkeiten von partial clone und LFS

  • 1. Minimale Checkout-Größe: Nur die neueste Version wird bezogen, die vollständige Dateihistorie wird ausgelassen
  • 2. Schnelles Klonen: Da keine großen Dateien übertragen werden, ist clone schneller
  • 3. Schnelles Setup: Anders als bei shallow clone bleibt Zugriff auf die gesamte Projekthistorie möglich

• Beispiel für den Einsatz von partial clone

  • Ein Beispiel für Klon-Geschwindigkeit und Speicherverbrauch bei einem Repository mit viel Historie großer PNG-Dateien:
    • Normales Klonen dauert fast 4 Minuten und belegt 1,3 GB
    • Mit partial clone und einem Blob-Limit von 100 KB ist das Repository in 6 Sekunden geklont und belegt 49 MB
    • Gegenüber dem Original verbessert sich die Klon-Geschwindigkeit um 97 %, die Checkout-Größe sinkt um 96 %

• Grenzen von partial clone

  • Wenn gefilterte Daten benötigt werden (z. B. git diff, git blame, git checkout), fordert Git die Datei vom Server an
  • Das ist dieselbe Eigenschaft wie bei Git LFS
  • In der Praxis ist es selten, dass man für Binärdateien blame ausführen muss

Probleme von Git LFS

• Starker Vendor-Lock-in: Die GitHub-Implementierung unterstützt nur eigene Server und führt zu Gebühren sowie Abhängigkeiten
• Kostenproblem: Für 50 GB Speicher kostet GitHub LFS 40 US-Dollar pro Jahr, Amazon S3 13 US-Dollar
• Schwer rückgängig zu machen: Nach einer Umstellung auf LFS ist eine Rückkehr ohne Umschreiben der Historie nicht möglich
• Fortlaufender Setup-Aufwand: Alle Beteiligten müssen LFS installieren; fehlt die Installation, erscheinen statt Dateien nur Metadaten-Dateien, was Verwirrung stiftet

Ausblick: Large Object Promisor

• Große Dateien verursachen auch auf Hosting-Plattformen wie GitHub und GitLab Kostenprobleme
• Git LFS senkt Serverkosten, indem große Dateien auf ein CDN ausgelagert werden

• Was ist Large Object Promisor?

  • Anfang dieses Jahres hat Git eine Funktion namens large object promisor offiziell gemergt
  • Diese Funktion reduziert ähnlich wie LFS die Speicherlast auf Serverseite, verringert aber die Komplexität für Nutzer deutlich
    > Diese Arbeit zielt darauf ab, serverseitige Vorgänge zu verbessern, insbesondere bei bereits binär komprimierten großen Blobs
    > Es handelt sich um eine Lösung als Alternative zu Git LFS
    > – Large Object Promisors, git-scm.com

• Funktionsweise

  • 1. Nutzer pushen große Dateien zu einem Git-Host
  • 2. Der Host lagert große Dateien an ein Backend-Promisor aus
  • 3. Beim Klonen liefert der Git-Host dem Client Informationen über den Promisor
  • 4. Der Client lädt die großen Dateien bei Bedarf automatisch von diesem Promisor herunter

• Aktueller Stand und Herausforderungen

  • Der Large Object Promisor befindet sich noch in Entwicklung; im März 2025 wurde ein Teil des Codes in Git gemergt
  • In GitLab und anderswo laufen zusätzliche Implementierungen und Diskussionen zu offenen Problemen
  • Bis zur breiten Einführung wird es noch Zeit brauchen
  • Vorerst bleibt die Abhängigkeit von Git LFS für die Speicherung großer Dateien unvermeidlich
  • Sobald sich der Promisor verbreitet, dürfte auch auf GitHub das Hochladen von Dateien über 100 MB möglich werden

Fazit: Die Zukunft großer Dateien in Git ist Git

• Das Git-Projekt beschäftigt sich stellvertretend für euch fortlaufend mit dem Problem großer Dateien
• Derzeit ist Git LFS weiterhin notwendig
• Doch mit der Weiterentwicklung von partial clone und large object promisors wird Git LFS nach und nach überflüssig, und bald dürfte eine Zeit kommen, in der sich große Dateien allein mit Git einfach verwalten lassen
• In Zukunft wird nur noch die Idee, eine MP3-Bibliothek in Git abzulegen, das letzte Hindernis für den Einsatz großer Dateien sein