Git 2.56.0 chega com merge-base mais rápido e repacks menores

O Git 2.56.0 foi lançado. Junio C Hamano, que mantém o Git, anunciou a versão em 28 de setembro de 2026. A maior parte dos ganhos tem a ver com velocidade e espaço em disco. Uma consulta de merge-base no kernel do Linux agora leva 3.887 passos em vez de 167.441. Uma nova forma de empacotar repositórios encolheu em 71% um grande repositório de teste.

A versão traz 748 commits que não são merges desde que o Git 2.55 saiu em junho, segundo o anúncio de Hamano. Eles vieram de 104 desenvolvedores, e 39 deles contribuíram com o Git pela primeira vez.

O Tech AI Wire antecipou os novos comandos do candidato a versão na semana passada, incluindo git history drop e git branch --delete-merged. Este texto cobre o que as notas da versão final, o GitHub e o GitLab acrescentam a isso.

Merge-base fica até 70 vezes mais rápido

Uma merge base é o commit mais recente que dois branches compartilham. O Git a calcula toda vez que você faz merge, faz rebase ou pergunta o quanto um branch se afastou do main. Em um repositório grande, essa caminhada de volta pelo histórico pode ser lenta.

O Git 2.56 interrompe a caminhada mais cedo. O anúncio de Hamano diz que o Git agora para "quando os commits exclusivos de um dos lados na fila se esgotam". Em termos simples, assim que o Git consegue provar que um branch não tem mais nada a oferecer, ele para de procurar.

O post de destaques do GitHub coloca números na mudança. Uma consulta de merge-base no kernel do Linux caiu de 167.441 passos, em 0,29 segundo, para 3.887 passos, em 0,01 segundo. Em dois grandes monorepos, o GitHub mediu uma aceleração de 70 vezes em um e uma aceleração média de 20 vezes no outro.

Uma mudança relacionada reaproveita respostas anteriores dentro de comandos como git branch --contains, que lista os branches que incluem um determinado commit. Isso acelera as verificações que o Git faz para saber se um commit consegue alcançar outro.

Repositórios menores com repacks path-walk

O Git guarda o histórico em arquivos pack, que são pacotes comprimidos de objetos. O repack reescreve esses pacotes para economizar espaço. A opção --path-walk reúne os objetos um caminho de arquivo por vez antes de comprimir, de modo que as versões do mesmo arquivo são comparadas entre si.

No teste do GitHub com o repositório do Fluent UI, o pack encolheu de 558,5 MB para 164,4 MB. Isso é cerca de 71% menor. Na 2.56, os repacks path-walk também funcionam com bitmaps de alcançabilidade (reachability bitmaps) e ilhas delta (delta islands). Os servidores Git usam esses dois recursos para iniciar clones rapidamente e para manter separados os forks que compartilham armazenamento.

Clones parciais podem descartar arquivos grandes de novo

Um clone parcial baixa o histórico sem todos os arquivos grandes. Ele busca os blobs, o termo do Git para o conteúdo dos arquivos, só quando um comando precisa deles. Com o tempo, esses arquivos buscados se acumulam no disco.

O Git 2.56 adiciona uma forma de removê-los. O anúncio da versão diz que o git repack com --drop-filtered apaga blobs locais acima de um limite de tamanho que o servidor ainda pode fornecer. O post do GitHub dá um exemplo completo: git repack -a --filter=blob:limit=1m --drop-filtered. É uma etapa manual, não uma limpeza automática.

Correções de conflito mais seguras e logs mais claros

O git add --resolved prepara só os arquivos cujos conflitos de merge você corrigiu. A versão final também verifica esses arquivos em busca de marcadores de conflito que sobraram, as linhas <<<<<<< que o Git escreve em um arquivo com conflito. Isso torna mais difícil que um arquivo meio corrigido escape para dentro de um commit.

O git log --follow agora acompanha melhor um arquivo ao longo de um histórico com várias renomeações e merges. O git log --graph indenta os commits raiz, os que não têm pai, para que históricos separados se destaquem. A opção --no-graph-indent ou a configuração log.graphIndent controla isso.

O que vem depois da 2.56

A próxima versão não será a 2.57. O engenheiro do GitLab Karthik Nayak escreve que o Git planeja saltar para a 2.98 em dezembro de 2026. O Git 2.99 e o Git 3.0 estão previstos para a primavera de 2027. "Esse salto significativo serve como uma indicação, tanto para os mantenedores downstream quanto para os consumidores, de que uma grande mudança está chegando", escreve Nayak.

Essa mudança é a troca do Git 3.0 para SHA-256 e reftable como padrão, além do Rust como parte obrigatória do build.

O que isso significa para os desenvolvedores

A maioria dos desenvolvedores ganha a aceleração do merge-base só de atualizar. Ela importa mais em grandes monorepos e em jobs de CI que fazem rebase ou comparam branches muitas vezes por dia. Se o seu pipeline fixa um Git antigo dentro de uma imagem de contêiner, é essa fixação que fica entre você e o ganho.

Experimente o git add --resolved na próxima vez que um merge parar em conflitos. Ele substitui o hábito de rodar git add . no meio do merge, que prepara cada edição perdida na árvore junto com as correções.

Se você mantém um servidor Git ou grandes espelhos, teste o --path-walk em uma cópia de um repositório e compare os tamanhos dos packs. O resultado do Fluent UI vem de um único repositório, e a sua mistura de arquivos será diferente. Meça antes de mudar um job de repack em produção.

Por fim, planeje-se para o salto de versão. Um script que compara a saída de git --version e espera a 2.57 em seguida vai encontrar a 2.98 no lugar. Confira essas comparações agora, enquanto a mudança ainda está a meses de distância.