O Git 2.56 foi lançado em 28 de setembro com mudanças voltadas à resolução de conflitos, manutenção de branches, navegação de histórico e desempenho em repositórios grandes. A versão também amplia trabalho experimental para reescrita de histórico e incorpora contribuições de 104 pessoas, 39 delas participando pela primeira vez.
A página oficial de instalação do Git registra a versão 2.56.0 na data, enquanto o resumo técnico do GitHub detalha os recursos selecionados. As notas completas continuam sendo a referência para compatibilidade e correções específicas.
Conflitos ganham marcação explícita
Durante um merge, `git add arquivo` tem dois significados possíveis: colocar uma mudança comum no índice ou informar que um conflito foi resolvido. O Git 2.56 introduz `git add –resolved` para tornar a segunda intenção explícita.
O comando verifica se o caminho realmente pertence ao conjunto de conflitos antes de marcar a resolução. Isso reduz o risco de um script ou pessoa tratar como resolvido um arquivo que não estava naquele estado. O `git add` tradicional continua disponível, o que preserva os fluxos existentes.
Em equipes que usam interfaces gráficas, a mudança pode ser incorporada gradualmente pelas ferramentas. O artigo sobre GitHub Desktop 3.6 mostra como clientes visuais organizam worktrees, commits e conflitos sobre os mesmos mecanismos do Git.
Grandes repositórios recebem otimizações
A versão melhora o cálculo de merge bases, etapa usada para encontrar ancestrais comuns entre históricos. Também há avanços no path-walk usado por operações de empacotamento e manutenção. Esses pontos pesam mais em repositórios com muitos objetos, branches e anos de histórico.
O ganho real depende da topologia do repositório, da operação e do armazenamento. Uma otimização que reduz muito o tempo em um monorepo pode ser imperceptível em um projeto pequeno. A avaliação deve medir clone, fetch, manutenção, merge-base e repack com dados representativos.
Esse problema de escala aparece também em plataformas de hospedagem. A análise do GitLab Next-Gen SCM explica por que concorrência, volume de objetos e automação pressionam a arquitetura além do comando executado na estação de trabalho.
Branches e histórico recebem novos comandos
`git branch –delete-merged` oferece uma forma mais direta de remover branches já incorporadas. A opção reduz a necessidade de combinar listagem e exclusão manual, mas continua exigindo atenção ao branch de referência e às políticas do repositório remoto.
O Git 2.56 também inclui trabalho experimental em `git history drop`, voltado a remover partes do histórico durante reescritas. Recursos experimentais não devem entrar em automação crítica sem leitura da documentação, cópia verificável do repositório e teste em clone descartável. Reescrita muda identificadores de commits e pode exigir coordenação com todos os consumidores.
Adoção no fluxo diário
Equipes podem atualizar primeiro em ambiente de desenvolvimento, executar a suíte do projeto e testar merge, rebase, hooks, assinatura e integração com IDEs. Scripts que resolvem conflitos podem adotar `git add –resolved` depois de confirmar a versão mínima disponível em todas as máquinas e imagens de CI.
As otimizações de grandes repositórios devem ser comparadas com a versão anterior usando as mesmas operações. Comandos experimentais de histórico precisam permanecer fora do fluxo principal até que a equipe tenha procedimento de recuperação e aceite a mudança de hashes. Essas verificações delimitam onde as novidades do Git 2.56 entram sem alterar processos de forma acidental.
O que `git add –resolved` verifica
O novo modo trabalha apenas com caminhos não mesclados. Antes de atualizar o índice, o Git procura marcadores de conflito que ainda permanecem no arquivo. Se encontrar um marcador, recusa a operação. Quando vários caminhos são selecionados, a verificação é feita antes da atualização, evitando que metade do conjunto seja marcada e a outra metade falhe.
Esse comportamento é diferente de provar que a resolução está correta. Um desenvolvedor pode remover os marcadores e escolher conteúdo incompleto. O comando confirma duas condições mecânicas: o caminho estava em conflito e não contém os marcadores textuais procurados. Revisão, testes e leitura do diff continuam determinando a validade da resolução.
Também há casos sem marcadores. Conflitos envolvendo arquivo removido de um lado, binários ou certos tipos de renomeação precisam ser avaliados por estado do índice e intenção do usuário. `git add –resolved` aceita pathspecs, o que permite selecionar diretórios ou grupos, mas scripts devem tratar explicitamente esses formatos antes de automatizar a conclusão.
Um fluxo de resolução mais explícito
Após um merge ou rebase interrompido, `git status` continua sendo o ponto de partida. A pessoa abre cada caminho, decide a versão, executa testes relevantes e inspeciona o diff. Em clientes compatíveis com 2.56, pode então usar:
git add --resolved caminho/do/arquivo
git diff --check
git diff --cachedO primeiro comando comunica a intenção; `git diff –check` procura problemas como espaços indevidos e marcadores restantes no conteúdo acompanhado; o diff staged mostra exatamente o que seguirá para o commit. Nenhum deles substitui a suíte do projeto. Em um rebase, a continuidade ainda ocorre com `git rebase –continue`; em merge, com o commit correspondente.
Automação deve verificar `git version` antes de usar a opção. Se imagens de CI, estações e ambientes de recuperação estiverem em versões diferentes, um script comum pode falhar. A adoção gradual pode manter `git add` como fallback até que a versão mínima do parque seja 2.56.
A melhoria no cálculo de merge base
Encontrar o melhor ancestral comum é parte de merge, rebase e comparações entre linhas de desenvolvimento. Em históricos grandes e ramificados, a travessia pode visitar muitos commits que já não têm chance de alterar a resposta. O Git 2.56 melhora a condição de parada dessa busca, reduzindo trabalho em topologias favoráveis.
Não existe um percentual universal. O efeito depende de profundidade, quantidade de branches, merges e grafos redundantes. A medição pode usar operações representativas antes e depois da atualização, com cache controlado e o mesmo clone. Tempo de CPU, leitura de objetos e duração total ajudam a separar melhoria do Git de diferença de armazenamento.
O path-walk usado em empacotamento também recebeu trabalho de desempenho. Repack e manutenção influenciam servidores e clones locais com muitos objetos. Equipes que operam monorepos devem testar junto de commit-graph, multi-pack-index, partial clone e políticas atuais, porque o ganho aparece dentro desse conjunto.
Exclusão de branches mescladas
`git branch –delete-merged` torna explícita a remoção de branches que já foram incorporadas. A vantagem é expressar seleção e ação em um comando planejado para esse caso, em vez de encadear saída textual de listagem com outra ferramenta. Ainda é necessário saber em relação a qual referência a integração está sendo avaliada.
Branches locais não são branches remotas. Excluir a referência local não apaga automaticamente a correspondente no servidor. Políticas de proteção, pull requests e retenção podem exigir que a limpeza remota ocorra por outro fluxo. Antes de automatizar, a equipe deve testar nomes incomuns, worktrees ativas e referências que não apontam para o branch principal esperado.
`git history drop` permanece experimental
O comando experimental explora a remoção de partes do histórico durante uma reescrita. Esse tipo de operação pode ser necessário para retirar conteúdo sensível ou reduzir um conjunto, mas muda hashes de commits e força consumidores a reconciliar novas referências. Backup verificável e clone descartável são requisitos mínimos.
O teste deve confirmar tags, branches, assinaturas, submódulos e referências usadas por automações. Depois da reescrita, todos os clones antigos ainda contêm os objetos até limpeza e podem reenviar referências. Portanto, remover um segredo do histórico não substitui revogar a credencial imediatamente.
Como o recurso está em evolução, sua sintaxe e comportamento não devem ser assumidos como contrato estável. A documentação da versão instalada e um procedimento de recuperação valem mais que incorporar o comando a um runbook antigo sem revisão.
Roteiro de atualização para equipes
A página de instalação oficial confirma a versão, e o resumo do GitHub apresenta os destaques, mas a adoção deve começar pelas notas da plataforma usada. Pacotes de macOS, Linux, Windows, IDEs e imagens de CI podem chegar em datas distintas.
Um piloto pode cobrir clone, fetch, merge, rebase, assinatura, hooks, Git LFS, submódulos e ferramentas visuais. Repositórios grandes devem registrar tempos antes da troca. Fluxos de conflito precisam incluir um caso textual, uma exclusão e um arquivo binário para mostrar onde `–resolved` ajuda e onde a decisão continua manual.
O Git 2.56 mantém compatibilidade com `git add`, portanto não exige alterar todo o processo no dia da atualização. O ganho imediato é disponibilizar uma intenção mais segura para conflitos e otimizações internas. Novos comandos podem entrar apenas depois que clientes, CI, documentação e procedimentos de recuperação reconhecem a mesma versão.
