Git amend: corrija o último commit sem surpresas

Exemplo e condições

O exemplo usa um commit local comum com mensagem errada e uma alteração esquecida em src/parser.js. São dois reparos: só mensagem ou também conteúdo. Não é um exemplo para commit antigo, inicial ou merge. Troque caminho e mensagem pelos reais e comece pela ponta atual.

Inspecione antes de alterar

Leia status, último commit e diff --cached. O índice fornece conteúdo a um amend comum; arquivos preparados de outra tarefa podem entrar sem querer. Confira também o não preparado para saber o que fica fora. Veja se o original foi publicado, integrado ou usado por colegas antes de mudar sua identidade.

git status --short
git log -1 --oneline
git diff --cached
git diff

Mantenha referência ou checkout separado

Crie rescue/before-amend em HEAD para manter o objeto original e compará-lo. Isso não salva todos os arquivos locais: preserve os importantes separadamente. Reflog pode identificar estados antigos enquanto retidos, mas não garante objetos permanentes nem copia edições nunca confirmadas.

git branch rescue/before-amend HEAD

Primeiro fluxo

Para mudar somente a mensagem, --amend --only sem caminhos exclui alterações já preparadas. -m fornece o texto corrigido. Confira commit e índice depois: o trabalho preparado deve continuar disponível para outro commit. Incluir conteúdo do índice é o outro fluxo, embora ambos usem --amend.

git commit --amend --only -m "Fix parser error message"
git diff --cached

Escolha o outro resultado deliberadamente

Para incluir um arquivo omitido, prepare o caminho certo, examine todo o diff do índice e use --amend --no-edit para manter a mensagem. Outros arquivos preparados também entram, salvo exclusão deliberada. Execute verificações relevantes. Preparar hunks específicos ajuda a revisar, mas não prova a correção do commit combinado.

git add -- src/parser.js
git diff --cached
git commit --amend --no-edit

Limites e exceções

Se a ponta foi compartilhada, prefira um novo commit de correção. Publicar uma ponta reescrita pode exigir coordenação e ser proibido pela proteção da branch. Não oferecemos force push genérico. Se a equipe permite reescrita, siga seu procedimento separado de lease, branch e conferência com colaboradores.

git add -- src/parser.js
git diff --cached
git commit -m "Correct parser handling"

Conflitos e limpeza

Amend normalmente não tem sequência própria de resolução de conflitos. Falha de hook ou commit rejeitado exige conferir mensagem e status, não reset --hard automático. Se alterou conteúdo errado, compare primeiro com rescue/before-amend. Preserve cópias verificadas de arquivos locais antes de qualquer reset corretivo.

Confira o resultado

Compare mensagem e arquivos dos dois commits. IDs diferentes são normais. Para somente mensagem, as árvores devem coincidir; para conteúdo, só o patch pretendido deve mudar. Confira o trabalho preparado restante e mantenha o resgate até a substituição revisada integrar o histórico desejado com segurança.

git show --stat HEAD
git diff rescue/before-amend HEAD
git status --short

Perguntas frequentes

No-edit impede mudança de conteúdo? Não: mantém a mensagem, mas o índice pode alterar conteúdo. Amend corrige um commit antigo? Não diretamente; requer outro fluxo. Depois do push? Só com política explícita de histórico compartilhado; um commit adicional evita muitos problemas de coordenação.

Revise a operação no FluxGit

Use o histórico visual e a visão de alterações do FluxGit para revisar a operação e os commits relevantes. Mantenha as verificações de branch, compartilhamento e arquivos locais do exemplo. A página de download apresenta os builds e plataformas disponíveis.

Referências oficiais do Git

• git-commit
• git-diff
• git-reflog