A evolução do Git para os próximos 10 anos

• O Git, usado por desenvolvedores no mundo todo, está promovendo mudanças estruturais visando a próxima década, com reformas importantes focadas em segurança, escalabilidade e usabilidade
• A mudança mais visível é a transição de SHA-1 para SHA-256; embora o uso de SHA-1 deva ser proibido até 2030, a adoção está atrasada por falta de suporte no ecossistema
• Com a adoção do Reftable, está em andamento uma tentativa de gerenciar com eficiência centenas de milhões de referências e resolver limitações do sistema de arquivos e problemas de concorrência
• Para melhorar o tratamento de arquivos grandes, estão sendo desenvolvidos Large-object promisors e um banco de dados de objetos plugável, integrados gradualmente a partir do Git 2.50
• Influenciado por sistemas emergentes de controle de versão como o Jujutsu, o Git busca oferecer suporte a fluxos de trabalho modernos por meio da simplificação da UI e da adição de novos comandos

---

A necessidade de mudança no Git

• Desde seu lançamento em 2005, o Git se consolidou como uma ferramenta central da qual dependem milhões de repositórios e inúmeros scripts há 20 anos
  • No entanto, mudanças no ambiente como vulnerabilidades de segurança do SHA-1, crescimento de repositórios grandes e expansão de pipelines de CI expuseram limitações estruturais
• Em 2017, o ataque SHAttered da CWI e do Google comprovou a possibilidade de colisões no SHA-1
  • Com o aumento do poder computacional de GPUs, grandes organizações passaram a ter capacidade de calcular colisões de hash
• Em vez de um redesenho revolucionário, o Git precisa optar por uma evolução gradual, promovendo mudanças sem perder compatibilidade com o ecossistema existente

Transição para SHA-256

• O suporte a SHA-256 foi adicionado no Git 2.29 (outubro de 2020), mas grandes plataformas como o GitHub ainda não oferecem suporte
  • Git, Dulwich e Forgejo têm suporte completo; GitLab, go-git e libgit2 estão em estágio de suporte experimental
• Embora o SHA-1 seja usado apenas para verificação simples de integridade, todo o ecossistema — incluindo assinaturas, CI e scripts — opera assumindo resistência a colisões
• Regulamentações governamentais e corporativas exigem a remoção do SHA-1 até 2030, e o SHA-256 deve se tornar o padrão no Git 3.0
• Para viabilizar a transição do ecossistema, recomenda-se que os usuários participem por meio de testes de ferramentas e pedidos de suporte às forges

Adoção do Reftable

• O Git tradicional usa uma estrutura de referências soltas em que cada referência é armazenada como um arquivo individual
  • Em repositórios com dezenas de milhões de referências, isso é ineficiente e causa problemas de sensibilidade a maiúsculas e minúsculas no sistema de arquivos e inconsistências de concorrência
• O Reftable é uma estrutura tabular baseada em formato binário, que permite atualizações atômicas e gerenciamento eficiente de referências
  • No caso de um repositório do GitLab com 20 milhões de referências, o arquivo packed-refs existente exigia reescrita de 2 GB
• No Git 3.0, o Reftable deve se tornar o backend padrão, e recomenda-se usar comandos do Git em vez de acesso direto a arquivos

Melhorias no tratamento de arquivos grandes

• O Git é eficiente na compressão de arquivos de texto, mas ao modificar arquivos binários torna-se ineficiente porque recria o objeto inteiro
  • Segundo análise do GitLab, 75% do espaço de repositórios é ocupado por arquivos binários de 1 MB ou mais
• O recurso Large-object promisors permite armazenar objetos grandes em um repositório remoto separado e transferi-los via CDN ou API S3
  • A implementação do protocolo foi concluída entre o Git 2.50 e o 2.52, e já está em estágio de uso no lado do cliente
• O banco de dados de objetos plugável deve introduzir um formato de armazenamento dedicado para binários, com suporte a armazenamento incremental
  • O Git 2.53 introduz a interface unificada de banco de dados de objetos, e uma prova de conceito (PoC) é esperada no 2.54

Melhorias na interface do usuário

• Os comandos do Git vêm sendo criticados há muito tempo por sua complexidade e falta de consistência, enquanto o Jujutsu (JJ), baseado em Rust, surge como alternativa
  • O Jujutsu oferece realocação automática de histórico, tratamento de conflitos como dados e uma abordagem que trata commits como rascunhos
• O Git está incorporando parte das vantagens do Jujutsu sem quebrar os fluxos de trabalho existentes
  • No Git 2.54, devem ser adicionados os comandos git history split e git history reword
  • Há planos para adicionar mais subcomandos de edição de histórico no futuro
• Steinhardt enfatiza que o Git está aprendendo com a concorrência e avançando em modernização da UI e melhoria da usabilidade

[GN⁺]

Comentários do Hacker News

• Git é realmente um software lindo, mas também expõe toda a complexidade centrada em programadores
  Já tentei ensinar Git para pessoas que não são da área de desenvolvimento, e elas não conseguiram aproveitar totalmente a força sutil das funcionalidades
  Sites como Learn Git Branching são ótimos recursos de aprendizado. Seria bom se esse tipo de UX estivesse incorporado à experiência padrão do Git — coisas como padrões intuitivos e um fluxo de aprendizado gradual
  Hoje em dia, com CLIs de agentes como Claude, Codex e OpenCode, dá para oferecer esse tipo de experiência com facilidade. Mas seria muito mais simples se o próprio Git oferecesse abstrações mais acessíveis

  • O problema não é que o Git expõe a complexidade, e sim que ele a expressa com termos e conceitos errados e uma documentação bagunçada

• Estou realmente animado com o Git 3.0, mas ao mesmo tempo já preparado para me frustrar imediatamente 😅
  jj ajudou muito os usuários de Git, porque mostrou que é possível ter um frontend de VCS mais intuitivo

  • Quanto mais concorrência houver, melhor para o ecossistema

• No GitLab, já vi um caso em que um arquivo packed-refs de 2 GB era reescrito a cada poucos segundos, e não consigo entender “por que isso estaria acontecendo”

  • E, sinceramente, nem sei se há algum motivo para o Git ou aquela pessoa terem que se importar com uma situação dessas

• Armazenar arquivos grandes externamente parece um passo em direção a um modelo centralizado, mas isso vai contra a filosofia de projeto original do Git

  • Não necessariamente. Isso é apenas uma questão de modelo de endereçamento e interface. Você pode usar um repositório central, mas também pode usar armazenamento distribuído como IPFS
  • Exato. Git é um DVCS, não um DVFS genérico. Eu precisava de um DVFS para armazenar documentos e acabei criando o meu próprio. É simples, rápido e funciona bem para esse propósito

• A transição para sair do SHA1 está demorando demais
  A função de hash deveria ter sido projetada desde o início de forma mais modular

• Acho que o Git precisa de um recurso para rastrear licenças de software por commit

  • Não entendi completamente o que isso quer dizer, mas isso não é papel do Git. Git é apenas um sistema de controle de código-fonte, e funcionalidades adicionais deveriam ser implementadas com ferramentas de extensão como git-annex
  • Se o Git tivesse esse tipo de recurso, ficaria pior. Commits já podem armazenar dados arbitrários, então basta colocar os metadados necessários no commit e processar isso com uma ferramenta separada
  • Dá para usar trailers, como no caso de código auxiliado por LLM
    Exemplo: Co-Authored-By: Whatever LLM, License: WTFPL