Zuletzt aktualisiert: 2026-06-29

Git-Repository-Größe

Die Clone-Größe eines Git-Repositorys setzt sich aus zwei Teilen zusammen: dem Arbeitsbaum mit den aktuellen Dateiversionen und der komprimierten History aller bisherigen Commits. Letztere wird in sogenannten Packfiles gespeichert und kann den aktuellen Stand um ein Vielfaches übersteigen – vor allem in langlebigen Projekten.

Berechnungsmodell

Die History-Größe $H$ ergibt sich aus der Commit-Anzahl $N$, der mittleren Änderungsgröße pro Commit $C$ und der Pack-Kompressionsrate $r$:

Die geschätzte Gesamtgröße eines Clones $T$ addiert die Arbeitsbaum-Größe $W$:

Die Kompressionsrate $r$ gibt den Anteil der unkomprimierten Delta-Daten an, der nach git-Delta-Kodierung und zlib-Kompression übrig bleibt. Bei $r = 0{,}3$ werden 30 % der ursprünglichen Delta-Daten im Packfile behalten – das entspricht einem Kompressionsverhältnis von etwa 3,3 : 1.

Rechenbeispiel

Ein Quellcode-Repository mit folgenden Kennzahlen:

• Arbeitsbaum: 80 MB
• Commit-Anzahl: 2.000
• Mittlere Änderungsgröße: 40 kB pro Commit
• Kompressionsrate: 30 %

Der Arbeitsbaum macht in diesem Beispiel etwa 77 % der Clone-Größe aus; die Pack-History knapp 23 %.

Einflussgrößen und Richtwerte

Kompressionsrate nach Repository-Typ

Binärdaten lassen sich von gits Delta-Kodierung kaum weiter komprimieren, weshalb Repositorys mit vielen Bildern oder Build-Artefakten oft deutlich größer werden als reine Quellcode-Projekte vergleichbarer Produktivität.

Mittlere Änderungsgröße pro Commit

Die tatsächliche mittlere Änderungsgröße lässt sich mit git log --stat oder git diff --stat ermitteln. Als grobe Faustregeln haben sich bewährt:

• Reine Quellcode-Commits: 10 – 100 kB
• Commits mit Konfigurationsdateien: 5 – 30 kB
• Commits mit Binary-Dateien oder automatisch generierten Artefakten: mehrere MB

Warum die History größer als der Arbeitsbaum werden kann

Git speichert jede Version jeder Datei als eigenes Objekt. Eine Datei, die in 500 Commits bearbeitet wurde, hinterlässt 500 Objekteinträge. Bei Projekten mit langer Laufzeit und vielen Mitwirkenden kann die kumulierte History den aktuellen Stand um ein Vielfaches übersteigen – auch mit git-Pack-Kompression. Das Verhältnis wächst in der Regel kontinuierlich, solange keine Branches bereinigt werden.

Strategien zur Größenreduktion

Shallow-Clone. git clone --depth N überträgt nur die letzten $N$ Commits der History. Bei einem Repository mit 20.000 Commits kann --depth 1 die Clone-Größe auf annähernd die Arbeitsbaum-Größe reduzieren – ein Rückgang von 90 % oder mehr ist bei alten Repositorys realistisch. Mit git fetch --unshallow lässt sich der vollständige Verlauf bei Bedarf nachladen.

Partial-Clone und Filter. Seit git 2.19 ermöglicht git clone --filter=blob:none das verzögerte Herunterladen von Datei-Blobs. Nur die für den aktuellen Checkout benötigten Blobs werden sofort abgerufen; die History-Metadaten bleiben vollständig. Auf Plattformen wie GitHub und GitLab ist diese Option unterstützt.

Repack und Garbage Collection. git gc --aggressive oder git repack -adf konsolidieren verstreute Objekte in optimierte Packfiles. In sehr aktiven Repositorys kann dies die Packfile-Größe merklich senken, ohne historische Informationen zu verlieren.

git-lfs für große Binärdaten. Repositorys, die große Binärdateien versionieren müssen, profitieren von Git Large File Storage (git-lfs). Binäre Assets werden ausgelagert; das Repository selbst enthält nur Zeiger, was die Pack-Größe drastisch reduziert.

Ist-Größe ermitteln

Das vereinfachte Modell liefert eine Größenordnung; die tatsächliche Pack-Größe hängt von Faktoren ab, die sich schwer pauschal schätzen lassen (Delta-Kettentiefe, Repack-Geschichte, Objekt-Metadaten). Den genauen On-Disk-Wert liefert:

git count-objects -vH

Der Wert size-pack gibt die aktuelle Größe aller Packfiles in lesbarer Form aus. Für eine detailliertere Aufschlüsselung nach Verzeichnis oder Dateityp eignet sich git-sizer (GitHub-Projekt), das auch Delta-Kettentiefe und Blob-Verteilung analysiert.

Weiterführende Rechner

Die Übertragungszeit für einen Clone in Abhängigkeit von Bandbreite und Latenz schätzt der Datenübertragungszeit-Rechner. Wie stark Packfiles durch Delta-Kodierung und zlib komprimiert werden können, zeigt der Kompressionsverhältnis-Rechner.