Git 2.56 adiciona history drop e delete-merged

O Git 2.56 está em forma de candidato a versão e é esperado para o fim de setembro de 2026. A LWN.net informou que a versão traz mais de 700 commits que não são merges. A maioria é encanamento. Mas um punhado de comandos novos muda o que um desenvolvedor consegue fazer sem recorrer a um rebase interativo.

A LWN chama a 2.56 de "uma versão sólida" e diz que o projeto está "guardando boa parte do seu trabalho mais importante para o futuro". Esse futuro é o Git 3.0.

Os comandos novos

Comando ou opção	O que faz
git history drop	Remove de um branch os commits indicados, reaplicando os que vêm depois
git repo info	Imprime os caminhos do repositório, absolutos e relativos
git add --resolved	Prepara apenas os caminhos de merge cujos conflitos você resolveu
git branch --delete-merged	Apaga branches locais já mesclados no seu branch de rastreamento remoto
git bisect --reset-when-found	Restaura o estado original assim que o bisect acha o commit
git replay --linearize	Descarta commits de merge enquanto reaplica o histórico
git refs	Cria, apaga, atualiza e renomeia referências diretamente

O que o history drop faz, e onde ele para

O git history drop remove de um branch um commit que você indica. Ele funciona reaplicando cada commit que veio depois. Esse é o trabalho que hoje se faz com um rebase interativo, digitado com cuidado, linha por linha.

Há um limite que vale conhecer antes de contar com ele. As notas de versão do Git dizem que o comando ainda se recusa a funcionar se o histórico contiver commits de merge. Muitos branches reais contêm merges. O comando serve mais a um branch de funcionalidade linear do que a um branch compartilhado de vida longa.

O git replay --linearize chega ao mesmo terreno pelo outro lado. Ele descarta commits de merge enquanto reaplica, o que achata um histórico emaranhado em uma linha reta.

Mudanças menores que você vai notar

O git add --resolved mira uma bagunça comum no meio de um merge. Durante um conflito é frequente consertar dois arquivos e deixar outras edições na árvore de trabalho. A opção nova prepara apenas os caminhos cujos conflitos você resolveu, e deixa suas outras mudanças locais em paz.

O git branch --delete-merged limpa branches locais que já foram mesclados no branch que eles seguem. O Git também imprime uma mensagem mais clara quando um desses branches está em uso para uma bisseção.

As notas de versão do projeto Git listam vários ajustes mais silenciosos. O Git agora percebe erros de digitação em comandos como git push origin/main. Uma nova configuração fetch.followRemoteHEAD controla como um fetch trata o branch padrão do remoto. Pedir ajuda a qualquer comando agora termina com código 0 em vez de 129, o que impede um script de ler um pedido de ajuda como falha. Comandos de configuração tentam de novo quando colidem, o que reduz erros de trava quando dois comandos escrevem ao mesmo tempo.

Por baixo, o git cat-file --batch formata a saída mais rápido, e o git log --follow lida melhor do que antes com histórico não linear.

O que isso significa para desenvolvedores

Teste o git history drop em uma cópia de um branch antes de confiar nele em um de verdade. A restrição dos commits de merge decide se ele cabe no seu fluxo de trabalho. Rode git log --merges no intervalo que você quer editar: se imprimir qualquer coisa, o comando vai recusar.

O git branch --delete-merged é o que vale virar hábito. A maioria dos desenvolvedores acumula dezenas de branches locais parados e os limpa com um encadeamento de shell copiado de um blog anos atrás. Uma opção embutida é mais segura, porque confere o branch de rastreamento remoto em vez de comparar nomes.

A mudança de código de saída merece uma revisão das suas próprias ferramentas. Qualquer script que tratava 129 como o sinal de um pedido de ajuda vai ver 0 agora. Esse é o comportamento correto, mas é uma mudança de comportamento, e ela falha em silêncio em vez de alto.

Nada aqui quebra um repositório existente. As mudanças que vão quebrar estão na versão seguinte: o Git 3.0 passa repositórios novos para SHA-256 e reftable, e torna o Rust uma dependência obrigatória de build. O próprio documento de mudanças incompatíveis do Git ainda não dá data para a 3.0. Trate a 2.56 como a última parada tranquila antes dela.