Como reduzimos em 94% o tamanho do git de um monorepo JavaScript

• O 1JS, o grande monorepo JavaScript da Microsoft, tem um volume enorme de código e contribuições. Um clone recente do repositório chegou a 178GB.
• O repositório ficou tão grande que alguns usuários na Europa não conseguiam cloná-lo.

Lição #1

• Quando entrou no repositório alguns anos atrás, percebeu que ele estava crescendo rapidamente. Quando fez o primeiro clone, tinha 1~2GB, mas alguns meses depois já havia chegado a 4GB.
• Usou a ferramenta git-sizer para verificar blobs grandes, o que acontece quando binários são incluídos por engano no check-in. Isso pode ser evitado usando o recurso de limite de tamanho de check-in do Azure DevOps.
• O problema também ocorreu porque os arquivos de alteração do Beachball não eram removidos. De forma semelhante ao Changesets, ele é usado para aumentar automaticamente o intervalo de semver dos pacotes.
• A lição aprendida foi não manter milhares de arquivos em uma única pasta. Para resolver isso, foi enviado um pull request para o Beachball para tratar várias alterações em um único arquivo, e foi criado um pipeline para limpar periodicamente a pasta de alterações.

Lição #2

• O branch versioned, que espelha o main, estava ficando cada vez mais difícil de clonar. Embora apenas os arquivos CHANGELOG.md e CHANGELOG.json tivessem sido alterados, ele estava trazendo 125GB adicionais de dados git.
• Foi descoberto um problema em um código antigo de empacotamento enviado por Linux Torvalds, que fazia a compactação comparando apenas os últimos 16 caracteres do nome do arquivo. Por causa disso, o git continuava enviando repetidamente o arquivo inteiro ao compará-lo com arquivos CHANGELOG.md de outros pacotes.
• O tamanho do repositório foi reduzido usando o comando git repack -adf --window=250, e com o novo comando git repack -adf --path-walk caiu de 178GB para 5GB.
• Foi adicionada a configuração git config --global pack.usePathWalk true para que deltas corretos sejam gerados durante o git push.

Encerramento

• Em monorepos grandes, quando arquivos com nomes longos como CHANGELOG.md são atualizados com frequência, vale a pena prestar atenção ao recurso path walk.
• É possível usar o comando git survey para verificar os principais arquivos por tamanho em disco, os principais diretórios por tamanho expandido e mais.
• A Microsoft está desenvolvendo soluções para expansão de repositórios e disponibilizando isso para o mundo todo.

Resumo do GN⁺

• Este texto compartilha a experiência de como reduzir o tamanho do git em um grande monorepo JavaScript. Em especial, o tamanho do repositório foi drasticamente reduzido ao resolver um problema em um código antigo de empacotamento do git.
• O texto traz informações úteis para resolver problemas relacionados ao git que podem surgir em projetos de grande porte. Em particular, explica como lidar com problemas causados por atualizações repetidas em arquivos como CHANGELOG.md.
• Projetos com funcionalidades semelhantes incluem o Buck, do Facebook, e o Bazel, do Google. Essas ferramentas podem ajudar a gerenciar grandes bases de código com eficiência.

[GN⁺]

Comentários do Hacker News

• O novo comando git-survey ainda não foi incluído no git.git. Ele foi adicionado no fork do Git da Microsoft

• Ao clonar nixpkgs, a opção --window 250 reduziu o tamanho para 1,7 GB. A opção --path-walk do fork do Git da Microsoft reduziu para 1,9 GB

  • Ambas as opções reduziram para menos da metade do tamanho inicial
  • Seria bom poder executar isso no GitHub, e melhor ainda se fosse hospedado de uma forma que as pessoas pudessem controlar isso

• Alguns usuários na Europa dizem que não conseguem clonar repositórios grandes. Parece que não será possível clonar até que mudanças sejam feitas no lado do servidor

• Houve um problema causado pelo erro de não incluir o caminho completo no nome do arquivo. Estavam verificando apenas os últimos 16 caracteres

• Derick Stolee escreveu um blog sobre a estrutura interna do Git. Foi possível aprender muito sobre como reduzir o tamanho do git clone localmente e em CI

• Hackear o Git é divertido, mas fico me perguntando se não existe uma forma de evitar incluir 2.500 pacotes em um monorepo

• Seria bom se a Microsoft usasse o Azure DevOps internamente. Parece que os serviços do Azure só oferecem conectores nativos para o GitHub

• Ter alguém por perto que conhece bem a estrutura interna do Git é uma grande vantagem ao trabalhar em projetos grandes

• Obrigado por esta publicação. Foi de grande ajuda para o software de código aberto. Microsoft, GitHub e GitLab estão oferecendo muitas coisas boas

• Quero entender melhor a questão de verificar os últimos 16 caracteres versus o caminho completo. Tenho curiosidade sobre como isso se conecta à compressão delta, ao índice de pacotes e ao índice de múltiplos pacotes