EMZETT.
Login

Emzett Wiki

Git LFS und große Dateien in Repositories

Properties1
tagsglossar, git, werkzeuge

2 Min. Lesezeit

Git LFS und große Dateien in Repositories

Kurz: Git ist für Quelltext gemacht; große Binärdateien wie Videos oder Modelle blähen Repositories auf, und Git LFS lagert sie aus und speichert im Repository nur Verweise.

Genauer: Git speichert jede Version jeder Datei dauerhaft. Eine 100-MB-Datei, die zehnmal geändert wird, belegt schnell ein Gigabyte, und jeder Klon lädt die gesamte Historie. Plattformen begrenzen Dateigrößen (zum Beispiel GitHub: Warnung ab 50 MB, Sperre ab 100 MB pro Datei).

Im Detail

Das Problem

Große Binärdateien (Bilder in hoher Auflösung, Videos, Audio, Spiele-Assets, Datenbanken, KI-Modelle, Design-Dateien) lassen sich schlecht diffen und komprimieren. Das Repository wird groß und langsam (Klonen, Checkout), CI-Läufe dauern länger. Auch versehentlich committete große Dateien bleiben in der Historie, selbst wenn man sie später löscht.

Git LFS (Large File Storage)

git lfs install
git lfs track "*.psd" "*.mp4" "models/*.bin"   # Muster festlegen
git add .gitattributes
git add modell.bin
git commit -m "Modell hinzufügen"
git push

Im Repository liegt nur ein kleiner Zeiger (Pointer) mit Hash und Größe; die echte Datei liegt auf einem LFS-Server und wird beim Checkout geladen. Vorteile: schlanke Historie, schnelleres Klonen, Dateien nur bei Bedarf (git lfs pull, GIT_LFS_SKIP_SMUDGE=1). Nachteile: Zusatzwerkzeug, Kontingente/Kosten bei Anbietern, schwierigeres Aufräumen.

Alternativen

  • Große Dateien gar nicht ins Git: Speicherung in Objektspeicher (S3, Cloud Storage) oder Release-Artefakten und nur Verweis/Download-Skript.
  • DVC (Data Version Control) und Hugging Face Hub für Daten und KI-Modelle.
  • Git-Annex für sehr große Datenbestände.
  • Perforce/Plastic SCM für Spielestudios mit riesigen Assets.
  • Teilklone und Sparse Checkout (git clone --filter=blob:none) verringern Daten beim Klonen.

Aufräumen und Vorbeugen

.gitignore für Build-Ausgaben, Abhängigkeiten (node_modules), große Testdaten. Bei bereits eingecheckten Riesendateien: Historie mit git filter-repo oder BFG Repo-Cleaner bereinigen (Historie wird umgeschrieben: Team informieren, alle klonen neu). Größe prüfen: git count-objects -vH, git rev-list --objects --all | …. Pre-commit-Hook gegen große Dateien (check-added-large-files).

Siehe auch: gitignore und Submodule, Git-Hooks, Git