git history: reescrever commits sem rebase interativo

O comando git history, introduzido em caráter experimental no Git 2.54, resolve exatamente a dor de quem precisa corrigir um commit anterior sem montar um rebase interativo completo. Para dev solo, a rotina é conhecida: typo na mensagem, arquivo esquecido no commit errado, ou um commit gordo que deveria ter sido dois — situações triviais que o git rebase -i resolve, mas com fricção desproporcional ao problema. git history é a resposta do projeto Git pra esses casos simples.

Por que o rebase interativo trava o dev solo

O git rebase -i HEAD~N funciona, mas exige que você: saiba quantos commits quer voltar (o N), entenda a sintaxe do arquivo de instrução (pick, reword, squash, fixup, edit, drop), gerencie conflitos se algum commit intermediário tocou no mesmo arquivo, e force-push com consciência quando terminar. Para um typo em uma mensagem, esse ciclo leva mais tempo do que escrever o commit certo da primeira vez.

O problema se agrava porque git add -p e rebase interativo exigem contexto mental simultâneo — você precisa lembrar o estado do repositório enquanto edita instruções em um editor de texto. Dev solo que alterna entre código e Git várias vezes por hora paga um custo cognitivo real. É justamente aí que git history corta caminho.

O que é o git history e o que ele faz diferente

O Git 2.54 introduz o git history como um novo comando experimental desenhado para os casos mais simples de reescrita de histórico. A premissa é não abrir um editor interativo cheio de instruções — em vez disso, você descreve a operação diretamente na linha de comando, e o Git resolve o restante.

Internamente, git history ainda usa a maquinaria do rebase, mas esconde a camada de edição de instruções. Isso significa que os riscos são os mesmos — reescrever histórico publicado exige --force-with-lease e comunicação com o time — mas o caminho feliz para operações simples fica significativamente mais curto.

• Corrigir mensagem de commit sem abrir editor de instruções do rebase.
• Dividir um commit em dois ou mais commits menores.
• Descartar um commit específico sem tocar nos outros.
• Reordenar commits de forma declarativa.
• Squash de commits relacionados com mensagem final definida na linha de comando.

3 casos reais de uso com git history

Os exemplos abaixo assumem que você instalou o Git 2.54 ou superior. No macOS com Homebrew: brew upgrade git. No Ubuntu/Debian, via PPA do maintainer oficial ou compilação manual enquanto os repositórios upstream não atualizam.

Caso 1 — corrigir mensagem de commit (o typo clássico)

Você acabou de fazer um commit com git commit -m 'feat: adicioar autenticação via Stripe' e só percebeu o erro depois de rodar git log. Sem git history, o caminho mínimo é git commit --amend se for o commit mais recente, ou rebase interativo se já houver commits acima.

O ganho real aparece quando o commit não é o mais recente. Com rebase interativo você precisaria de git rebase -i HEAD~3, localizar o commit no editor, trocar pick por reword, salvar, e editar a mensagem em um segundo editor. Com git history, você referencia o hash diretamente:

Caso 2 — dividir um commit em dois

O caso mais comum para dev solo: você estava em flow, commitou tudo de uma vez, e agora o commit mistura uma feature com uma correção de bug não relacionada. Em revisão de PR — mesmo sendo o único revisor — commits limpos facilitam entender o diff semanas depois.

O git history split coloca os arquivos listados em --first no novo primeiro commit e os demais arquivos do commit original no segundo. Se precisar de mais de dois grupos, o comando aceita múltiplos --group com sintaxe análoga — consulte git history split --help para a referência completa, que pode mudar antes da estabilização.

Caso 3 — descartar commit do meio do histórico

Você fez um commit de debug (console.log ou debugger) três commits atrás e quer remover sem arrastar o restante do histórico. Com rebase interativo, troca pick por drop. Com git history, é uma linha:

git history vs rebase interativo: quando usar cada um

O git history não substitui o rebase interativo em todos os cenários. Para operações complexas — reordenar múltiplos commits com conflitos potenciais, fazer squash seletivo de 10+ commits, ou combinar histórico de duas branches — o rebase interativo ainda é a ferramenta certa. A tabela abaixo organiza a decisão:

A regra prática: se a operação cabe em um único subcomando de linha de comando sem ambiguidade, use git history. Se você precisa visualizar e reorganizar múltiplos commits de forma interdependente, abra o rebase interativo. Ambos coexistem — não é uma escolha definitiva.

Instalação e verificação do Git 2.54

O git history só está disponível a partir do Git 2.54. Antes de tentar qualquer comando, verifique sua versão instalada:

No Vercel, Netlify e GitHub Actions, a versão do Git disponível nos runners depende da imagem base. Se seus workflows dependem de operações de histórico dentro do CI, fixe a versão explicitamente ou adicione um step de instalação. Para uso local — que é o caso de uso principal do git history — a atualização manual via gerenciador de pacotes resolve.

Boas práticas de higiene de histórico para dev solo

Ter uma ferramenta nova não resolve o problema de base: commits mal formados desde o início. Algumas práticas que cortam a necessidade de reescrita retroativa:

• Conventional Commits — prefixos feat:, fix:, chore:, docs: tornam o git log --oneline legível sem esforço. Ferramentas como commitlint validam automaticamente.
• `git commit --patch` (`-p`) — faz stage interativo por hunk antes de commitar, evitando commits misturados antes de existirem.
• Commits pequenos e frequentes — são mais fáceis de descartar, dividir ou reordenar depois; commits de 500 linhas em um arquivo viram pesadelo de rebase.
• Branch por feature — isola o histórico sujo do main; você pode rebase limpo na branch antes de abrir PR.
• `git stash push -m 'wip: descrição'` — em vez de commitar WIP no meio de outra feature; limpa o histórico sem perder progresso.

Para quem usa feature flags no Next.js com Vercel Flags, a prática de branches por feature se encaixa naturalmente: cada branch habilita uma flag, o histórico fica isolado, e o merge pro main chega limpo. O git history entra como recurso de último minuto quando um commit escorregou.

Desenvolvedores que trabalham com segurança mínima em SaaS indie também se beneficiam de histórico limpo: quando um secret vazou em um commit, localizar e remover o commit específico com git history drop + git push --force-with-lease é mais rápido e menos arriscado do que rebase interativo em pânico.