Wie wir die Git-Größe unseres JavaScript-Monorepos um 94 % reduziert haben

 (jonathancreamer.com)
7 Punkte von GN⁺ 2024-10-28 | 1 Kommentare | Auf WhatsApp teilen
  • 1JS, Microsofts großes JavaScript-Monorepo, enthält eine enorme Menge an Code und Beiträgen. Ein frisch geklonter Repo erreichte zuletzt 178 GB.
  • Das Repo war so groß, dass einige Nutzer in Europa es nicht klonen konnten.

Lektion #1

  • Als ich vor einigen Jahren zum Repo dazukam, fiel mir auf, dass es sehr schnell wuchs. Beim ersten Klonen war es 1–2 GB groß, wenige Monate später bereits 4 GB.
  • Mit dem Tool git-sizer wurden große Blobs identifiziert; diese entstehen, wenn Binärdateien versehentlich eingecheckt werden. Mit der Funktion zur Begrenzung der Check-in-Größe in Azure DevOps lässt sich das verhindern.
  • Es gab Probleme, weil Beachball-Änderungsdateien nicht gelöscht wurden. Ähnlich wie Changesets wird dies verwendet, um den semver-Bereich von Paketen automatisch hochzustufen.
  • Eine wichtige Lehre war, nicht Tausende von Dateien in einem einzigen Ordner zu speichern. Um das zu beheben, wurde ein Pull Request für Beachball eingereicht, damit mehrere Änderungen in einer Datei verarbeitet werden können, und eine Pipeline geschrieben, die den Änderungsordner regelmäßig bereinigt.

Lektion #2

  • Der versioned-Branch, ein Mirror von main, wurde zunehmend schwerer zu klonen. Obwohl nur die Dateien CHANGELOG.md und CHANGELOG.json geändert wurden, wurden zusätzlich 125 GB an Git-Daten übertragen.
  • Es wurde entdeckt, dass alter Pack-Code, den Linux Torvalds eingecheckt hatte, beim Komprimieren nur die letzten 16 Zeichen des Dateinamens verglich. Dadurch pushte Git wiederholt ganze Dateien, indem es sie mit CHANGELOG.md-Dateien anderer Pakete verglich.
  • Mit dem Befehl git repack -adf --window=250 wurde die Größe des Repos reduziert, und mit dem neuen Befehl git repack -adf --path-walk sank sie von 178 GB auf 5 GB.
  • Durch Hinzufügen der Einstellung git config --global pack.usePathWalk true werden bei git push die richtigen Deltas erzeugt.

Abschluss

  • Wenn in großen Monorepos häufig Dateien mit langen Namen wie CHANGELOG.md aktualisiert werden, sollte man die Path-Walk-Funktion im Blick behalten.
  • Mit dem Befehl git survey lassen sich unter anderem die größten Dateien nach Speicherplatzverbrauch und die größten Verzeichnisse nach aufgeblähter Größe prüfen.
  • Microsoft entwickelt Lösungen für die Skalierung von Repositories und stellt sie weltweit zur Verfügung.

Zusammenfassung von GN⁺

  • Dieser Artikel teilt Erfahrungen dazu, wie sich die Git-Größe eines großen JavaScript-Monorepos reduzieren lässt. Insbesondere wurde das Problem in altem Git-Pack-Code gelöst, wodurch die Repo-Größe massiv sank.
  • Der Artikel bietet nützliche Informationen zur Lösung von Git-Problemen, die in großen Projekten auftreten können. Besonders erklärt er, wie sich Probleme durch wiederholte Updates von Dateien wie CHANGELOG.md beheben lassen.
  • Vergleichbare Projekte mit ähnlicher Zielsetzung sind Facebooks Buck oder Googles Bazel. Solche Tools können helfen, große Codebasen effizient zu verwalten.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-10-28
Hacker-News-Kommentare

  • Der neue Befehl git-survey ist noch nicht in git.git enthalten. Er wurde im Git-Fork von Microsoft hinzugefügt.

  • Beim Klonen von nixpkgs reduzierte die Option --window 250 die Größe auf 1,7 GB. Die Option --path-walk aus dem Microsoft-Git-Fork reduzierte sie auf 1,9 GB.

    • Beide Optionen reduzierten die anfängliche Größe auf weniger als die Hälfte.
    • Es wäre gut, wenn man das auf GitHub ausführen könnte, und noch besser, wenn es dort gehostet würde, sodass die Leute es steuern könnten.

  • Einige Nutzer in Europa sagen, dass sie große Repositories nicht klonen können. Bis Änderungen auf Serverseite vorgenommen werden, scheint Klonen nicht möglich zu sein.

  • Das Problem entstand durch einen Fehler, bei dem der vollständige Pfad nicht im Dateinamen enthalten war. Es wurden nur die letzten 16 Zeichen geprüft.

  • Derick Stolee hat einen Blogbeitrag über die interne Struktur von Git geschrieben. Daraus konnte man viel darüber lernen, wie sich die Größe von git clone lokal und in CI reduzieren lässt.

  • Es macht Spaß, an Git herumzuhacken, aber ich frage mich, ob es einen Weg gibt, nicht 2.500 Pakete in ein Monorepo aufzunehmen.

  • Es wäre gut, wenn Microsoft Azure DevOps selbst nutzen würde. Es scheint, als würden Azure-Dienste nur native Konnektoren für GitHub bereitstellen.

  • Jemanden in der Nähe zu haben, der sich mit den internen Strukturen von Git gut auskennt, ist ein großer Vorteil, wenn man an großen Projekten arbeitet.

  • Danke für diesen Beitrag. Er war eine große Hilfe für Open-Source-Software. Microsoft, GitHub und GitLab liefern viele gute Dinge.

  • Ich würde das Problem mit den letzten 16 Zeichen und der Prüfung des vollständigen Pfads gern besser verstehen. Ich frage mich, wie das mit Delta-Komprimierung, Paketindex und Multi-Paketindex zusammenhängt.