Cómo redujimos en 94% el tamaño git de nuestro monorepo de JavaScript

• 1JS, el gran monorepo de JavaScript de Microsoft, tiene una enorme cantidad de código y contribuciones. Un clon reciente del repositorio había llegado a 178 GB.
• El repositorio era tan grande que algunos usuarios en Europa no podían clonarlo.

Lección #1

• Cuando se unieron al repositorio hace algunos años, notaron que crecía rápidamente. Cuando lo clonaron por primera vez tenía 1–2 GB, pero unos meses después ya había llegado a 4 GB.
• Usaron la herramienta git-sizer para identificar blobs grandes, algo que ocurre cuando se hace check-in de binarios por error. Esto puede evitarse usando la función de límite de tamaño de check-in de Azure DevOps.
• También hubo problemas por no eliminar los archivos de cambios de Beachball. Al igual que Changesets, se usa para aumentar automáticamente el rango semver de los paquetes.
• Aprendieron que no conviene guardar miles de archivos en una sola carpeta. Para resolverlo, enviaron un pull request a Beachball para procesar varios cambios en un solo archivo y escribieron un pipeline para limpiar periódicamente la carpeta de cambios.

Lección #2

• La rama versioned, que era un espejo de main, se volvió cada vez más difícil de clonar. Aunque solo cambiaban los archivos CHANGELOG.md y CHANGELOG.json, se estaban trayendo 125 GB adicionales de datos git.
• Descubrieron que un código antiguo de empaquetado incorporado por Linux Torvalds realizaba la compresión comparando solo los últimos 16 caracteres del nombre del archivo. Por eso git seguía empujando repetidamente el archivo completo al compararlo con archivos CHANGELOG.md de otros paquetes.
• Redujeron el tamaño del repositorio usando el comando git repack -adf --window=250, y con el nuevo comando git repack -adf --path-walk lograron bajarlo de 178 GB a 5 GB.
• Agregaron la configuración git config --global pack.usePathWalk true para que se generen los deltas correctos al hacer git push.

Cierre

• Si en un monorepo grande se actualizan con frecuencia archivos de nombre largo como CHANGELOG.md, vale la pena prestar atención a la función path walk.
• Con el comando git survey se pueden revisar los archivos principales por tamaño en disco, los directorios principales por tamaño expandido, etc.
• En Microsoft están desarrollando soluciones para escalar repositorios y ponerlas a disposición de todo el mundo.

Resumen de GN⁺

• Este artículo comparte la experiencia de cómo reducir el tamaño git de un gran monorepo de JavaScript. En particular, resolvieron un problema en un antiguo código de empaquetado de git y redujeron drásticamente el tamaño del repositorio.
• El texto ofrece información útil para resolver problemas relacionados con git que pueden surgir en proyectos grandes. En especial, explica cómo abordar los problemas causados por actualizaciones repetitivas de archivos como CHANGELOG.md.
• Proyectos con funciones similares incluyen Buck de Facebook y Bazel de Google. Estas herramientas pueden ayudar a administrar de forma eficiente grandes bases de código.

[GN⁺]

Comentarios de Hacker News

• El nuevo comando git-survey todavía no está incluido en git.git. Fue agregado en el fork de Git de Microsoft

• Al clonar nixpkgs, la opción --window 250 redujo el tamaño a 1.7 GB. La opción --path-walk del fork de Git de Microsoft lo redujo a 1.9 GB

  • Ambas opciones lo redujeron a menos de la mitad del tamaño inicial
  • Estaría bien poder ejecutar esto en GitHub, y sería aún mejor si se alojara de una forma en la que la gente pudiera controlarlo

• Algunos usuarios en Europa dicen que no pueden clonar repositorios grandes. Parece que no podrán clonarlos hasta que se hagan cambios del lado del servidor

• Hubo problemas por un error en el que los nombres de archivo no incluían la ruta completa. Solo se estaban revisando los últimos 16 caracteres

• Derick Stolee escribió un blog sobre la estructura interna de Git. Se pudo aprender mucho sobre cómo reducir el tamaño de git clone en entornos locales y de CI

• Hackear Git es divertido, pero me pregunto si habrá una forma de no incluir 2,500 paquetes en el monorepo

• Sería bueno que Microsoft usara Azure DevOps internamente. Parece que los servicios de Azure solo ofrecen conectores nativos para GitHub

• Tener cerca a alguien que conoce bien la estructura interna de Git es una gran ventaja al trabajar en proyectos grandes

• Gracias por esta publicación. Fue de gran ayuda para el software de código abierto. Microsoft, GitHub y GitLab están aportando muchas cosas buenas

• Me gustaría entender mejor el tema de revisar los últimos 16 caracteres frente a la ruta completa. Tengo curiosidad por cómo se relaciona con la compresión delta, el índice de paquetes y el índice multipaquete