Git 3.0 adotará SHA-256 por padrão e exigirá Rust

O Git 2.56-rc0 foi publicado em 11 de setembro de 2026, e é a versão seguinte que quebra coisas. O documento de mudanças incompatíveis do próprio Git lista o que a versão 3.0 muda para repositórios novos. Eles vão usar hashes SHA-256 em vez de SHA-1, guardar referências no formato reftable e nomear o primeiro ramo como main. Compilar o Git também passará a exigir Rust. A Phoronix noticiou a versão candidata e situa o Git 3.0 por volta do fim de 2026.

Cada um desses padrões vale apenas para repositórios criados depois da mudança. Os repositórios existentes continuam funcionando como estão.

Os quatro padrões que mudam

Padrão	Hoje	No Git 3.0
Algoritmo de hash	SHA-1	SHA-256
Armazenamento de referências	files	reftable
Nome do primeiro ramo	master	main
safe.bareRepository	all	explicit

A mudança de hash tem um argumento de segurança por trás. O documento do Git cita três ataques ao SHA-1 pelo nome: SHAppening em 2015, SHAttered em 2017 e Shambles em 2020. Uma colisão de hash em um sistema de controle de versão significa que dois objetos diferentes podem reivindicar a mesma identidade.

O reftable substitui o arranjo antigo, em que cada referência era um arquivo no disco. O documento do Git dá duas razões: ele se comporta corretamente em sistemas de arquivos do Windows e do macOS que ignoram maiúsculas e minúsculas, e tem melhor desempenho em repositórios com muitas referências.

A mudança de safe.bareRepository de all para explicit é menor, mas tem um ataque real atrás dela. O padrão atual deixa o Git descobrir um repositório bare em qualquer ponto de uma árvore de diretórios, inclusive um que um atacante tenha plantado dentro de uma cópia de trabalho.

Rust passa a ser obrigatório

A exigência de Rust chega em etapas. O documento do Git descreve a sequência: o suporte a Rust passou a ser detectado automaticamente no Git 2.52, veio ativado por padrão no 2.55 e se torna obrigatório no 3.0.

Isso coloca o Git ao lado de outros softwares de base que dão o mesmo passo; o Ubuntu está trocando os coreutils do GNU por implementações em Rust na próxima versão. Para quem compila o Git a partir do código em uma plataforma incomum, uma cadeia de ferramentas Rust passa a ser um pré-requisito a planejar.

O Git 3.0 também remove recursos obsoletos há anos, entre eles git pack-redundant, git whatchanged, o suporte a arquivos graft e mecanismos antigos de armazenamento de remotos.

O que o próprio 2.56 traz

As notas da versão 2.56 tratam principalmente de desempenho e encanamento. A enumeração de objetos soltos durante o git status cai de complexidade quadrática para O(n log n). O cálculo da base de mesclagem para mais cedo quando pode, o que as notas descrevem como ganhos significativos.

Há uma superfície de comando nova: o git refs ganha subcomandos para criar, apagar, atualizar e renomear referências. O texto de aviso do git status agora nomeia o remoto e o ramo no git pull que sugere quando o seu ramo e o upstream divergiram.

A Phoronix nota que o 2.56 também adiciona padrões de diff para Swift, cobrindo atributos, modificadores, inicializadores falíveis e genéricos, e reforça o backend de mesclagem ORT contra árvores corrompidas. Por baixo, a versão segue removendo variáveis globais em favor de estado por repositório, o que prepara bancos de objetos intercambiáveis.

O que isso significa para desenvolvedores

A questão de compatibilidade não é se o seu Git funciona, e sim se a sua forja acompanha. Um repositório SHA-256 precisa ser entendido por tudo que o toca, inclusive o seu provedor de hospedagem, os seus executores de integração contínua e qualquer ferramenta que interprete identificadores de objeto. Teste esse caminho antes de criar um repositório com o novo padrão.

Verifique no seu código suposições fixas sobre o tamanho do hash. Quarenta caracteres hexadecimais estão embutidos há vinte anos em scripts, expressões regulares e colunas de banco de dados. Nomes de objeto SHA-256 têm sessenta e quatro caracteres, e um varchar(40) simplesmente os corta.

O reftable vale adoção antecipada se você mantém repositórios com milhares de ramos ou tags, porque é ali que o formato compensa. O nome padrão do ramo é o que menos importa: a maioria dos times o definiu anos atrás, e um repositório criado após a mudança pode ser renomeado com um comando.