Desfazer no Git: restore, reset e revert (qual usar)

Escolha como desfazer pela localização da mudança. restore atua em arquivos, reset move a referência e opcionalmente stage e working tree, e revert cria um commit que inverte outro. Antes de qualquer um, rode git status e confirme se a mudança está só no disco, preparada, commitada localmente ou publicada.

O sandbox começou com três commits reais:

git --no-pager log --oneline -3

Decida pelo estado, não pelo comando lembrado

Pense em três transparências: working tree, stage e commit. Restore troca o conteúdo de uma transparência por outra; reset reposiciona a referência e pode alinhar as camadas; revert desenha uma nova transparência com o efeito inverso. O limite é que arquivos e diretórios não são folhas físicas. Sempre confirme a documentação da opção escolhida.

Restore descarta uma edição ainda no disco

Uma linha de preço inválido aparecia apenas na working tree:

git status --short
git restore catalogo.txt
git status --short

A segunda execução de git status --short, depois do restore, não escreveu nada: a working tree ficou limpa.

O comando substituiu o arquivo pelo conteúdo do stage, que naquele momento coincidia com HEAD. Essa edição não havia sido commitada; o reflog não tem uma versão para recuperar. Revise git diff catalogo.txt antes de descartar.

Restore staged retira da caixa sem apagar a bancada

Depois de preparar um novo livro, a letra estava na coluna do stage. A opção --staged devolveu a seleção para HEAD, mas preservou o arquivo editado:

git status --short
git restore --staged catalogo.txt
git status --short

Esse é o comando quando você adicionou o arquivo errado. Você não precisa commitar nem apagar o trabalho. Depois selecione apenas os caminhos que pertencem à decisão correta.

Reset move branch, stage e talvez arquivos

Os modos mudam quantas camadas acompanham o novo HEAD. --soft move a branch e mantém o conteúdo preparado. O padrão --mixed move a branch e redefine o stage, preservando a working tree. --hard alinha os três e descarta alterações rastreadas da working tree.

git reset --soft HEAD~1
git status --short

Nesse cenário didático, o commit saiu da ponta e sua mudança permaneceu pronta para outro commit. Não execute sobre uma branch compartilhada sem entender que o hash deixa de ser ancestral da ponta publicada.

git reset --mixed HEAD
git status --short

Agora a mudança ficou apenas na bancada. A palavra “mixed” não significa misturar commits; significa atualizar referência e índice, sem sobrescrever a working tree.

Revert preserva um erro que já faz parte da conversa

Quando o commit já foi enviado, criar uma compensação mantém o histórico que o time conhece. O teste reverteu o commit 49bc462:

git revert --no-edit 49bc4626e41687945f4057751d90784166a3aa7b

O log mantém causa e correção:

git --no-pager log --oneline -3

Revert pode conflitar se mudanças posteriores editaram a mesma região. Resolva como um merge: entenda o estado desejado, teste, prepare e continue. Não suponha que “inverter” sempre é uma subtração automática.

Amend corrige o último commit local

Se a mensagem ou um arquivo do último commit está errado e ninguém recebeu o hash, prepare a correção e recrie o commit:

git add README.md
git commit --amend -m "docs: detalha instalação da livraria"
git --no-pager log -1 --oneline

O hash muda mesmo que você altere apenas a mensagem, porque ela faz parte do objeto. Depois de push, amend normalmente exige atualizar o remoto com história reescrita. A lição de rebase explica a regra de não reescrever o que outras pessoas já puxaram.

Reflog encontra a ponta que reset removeu

Para provar a recuperação, o laboratório moveu HEAD dois commits para trás:

git reset --hard HEAD~2

O reflog registrou o local anterior:

git --no-pager reflog -4

Com o hash completo copiado da execução, a branch voltou:

git reset --hard e26f0a60192f8adff054762ad2dcb222c52f3f61

Isso recuperou commits porque os objetos ainda existiam. Não recuperaria uma linha nunca adicionada a commit ou stash. A prevenção continua melhor: git status, branch de segurança e backup antes de operações destrutivas.

Sua missão é criar um repositório descartável e demonstrar quatro casos: restore de working tree, retirada do stage, revert de commit e recuperação por reflog. Antes de cada comando, escreva qual camada muda. Termine quando o status confirmar sua previsão e você souber por que um push rejeitado não deve ser “resolvido” com reset ou force por impulso. Faça uma cópia do hash atual antes do exercício e compare o log depois de cada operação; essa referência torna visível quando o conteúdo foi preservado e quando o próprio histórico foi reescrito.