Wenn ein zentrales Code-Repository auf 87 Gigabyte angewachsen ist, leidet die gesamte Engineering-Organisation – von langsamen Clone-Zeiten bis hin zu gebremster CI/CD-Pipeline. Dropbox hat das Problem systematisch gelöst und dabei mehr als 75 Prozent des Repository-Volumens eingespart. Die eingesetzten Methoden sind ein Blaupause für jede skalierte Entwicklungsorganisation.
Dropbox reduziert Git-Monorepo von 87 GB auf 20 GB – Lektionen für skalierte Engineering-Organisationen
Dropbox hat sein zentrales Code-Repository von 87 Gigabyte auf rund 20 Gigabyte verkleinert – eine Reduktion um mehr als 75 Prozent. Die Maßnahmen, die das Engineering-Team dafür eingesetzt hat, sind für alle Organisationen relevant, die mit gewachsenen Codebasen und langsam werdenden Entwicklungsumgebungen kämpfen.
Das Problem: Monorepos wachsen still und stetig
Monorepos – einzelne, zentrale Repositories, die den gesamten Quellcode eines Unternehmens bündeln – sind in großen Engineering-Organisationen weit verbreitet. Unternehmen wie Google, Meta und Spotify setzen auf dieses Modell, weil es Code-Wiederverwendung, einheitliche Toolchains und konsistente Abhängigkeitsstrukturen vereinfacht.
Der Nachteil: Repositories akkumulieren über Jahre hinweg Daten, die operativ nicht mehr benötigt werden – große Binärdateien, veraltete Build-Artefakte, vollständige Commit-Historien.
Bei Dropbox hatte sich dieses Problem über Jahre aufgestaut: 87 GB bedeuten lange Clone-Zeiten, hohe Speicherkosten auf Entwickler-Workstations und CI/CD-Infrastruktur sowie spürbar langsamere Git-Operationen – mit direkten Auswirkungen auf die Produktivität des gesamten Engineering-Teams.
Maßnahmen: Partial Clones, Shallow History und Objekt-Bereinigung
Dropbox verfolgte mehrere parallele Ansätze:
Partial Cloning war das zentrale Werkzeug – eine Git-Funktion, die es erlaubt, beim initialen Checkout nur einen Teil der Repository-Objekte zu laden. Statt vollständiger Historien- und Blob-Daten erhalten Entwicklerinnen und Entwickler nur das, was für ihre aktuelle Arbeit notwendig ist.
Shallow Clones kamen auf der CI/CD-Seite zum Einsatz, bei denen nur ein begrenzter Ausschnitt der Commit-Historie geladen wird.
Parallel dazu bereinigten die Teams historische Binärdateien systematisch aus der Git-Objektdatenbank:
- Werkzeuge wie
git filter-repounterstützten den Bereinigungsprozess - Große, inaktive Dateien wurden entfernt oder in Git LFS (Large File Storage) ausgelagert
- Automatisierte Prüfungen sollen künftig verhindern, dass große Binärdateien erneut unbemerkt ins Repository gelangen
Technische und organisatorische Herausforderungen
Die Umsetzung war kein rein technischer Vorgang. Das nachträgliche Rewriting von Git-Historien erfordert, dass alle Entwicklerinnen und Entwickler ihre lokalen Kopien neu synchronisieren.
In Teams mit Dutzenden oder Hunderten von Personen ist das eine koordinationsintensive Operation, die sorgfältige Kommunikation und klare Rollout-Pläne voraussetzt.
Dropbox betont, dass die Maßnahmen iterativ eingeführt wurden – begleitet von einer umfangreichen internen Dokumentation. Dieser graduelle Ansatz minimierte Unterbrechungen im laufenden Entwicklungsbetrieb.
Einordnung für deutsche Unternehmen
Für Engineering-Teams in deutschen Unternehmen – insbesondere in der Software-Entwicklung, im Automotive-Umfeld oder in der Industrie, wo Codebasen über Jahrzehnte entstehen – ist der Dropbox-Ansatz ein praxisnahes Referenzbeispiel.
Die eingesetzten Werkzeuge sind Open Source und standardisiert; der eigentliche Aufwand liegt in:
- Analyse bestehender Repositories (Welche Objekttypen beanspruchen den meisten Speicher?)
- Definition klarer Bereinigungsrichtlinien (Welche Teile der Historie werden tatsächlich noch benötigt?)
- Organisatorische Koordination des Rollouts ohne Unterbrechung des Entwicklungsbetriebs
Unternehmen, die mit langen Build- und Clone-Zeiten kämpfen, sollten mit einer strukturierten Bestandsaufnahme beginnen – und erst dann gezielte Maßnahmen priorisieren.
Quelle: InfoQ – Dropbox Reduces Git Monorepo Through Optimization
