Git reset, revert ou restore? Qual usar para desfazer um erro

Você fez besteira no Git. Pode ser um arquivo que não devia ter mudado, um commit com a senha do banco ou um merge que quebrou a build. Os três comandos que aparecem nas respostas de fórum são reset, revert e restore, e eles parecem fazer a mesma coisa. Não fazem, e usar o errado num branch compartilhado é o jeito mais rápido de estragar a tarde de alguém.

A própria documentação do Git separa os três numa seção chamada “Reset, restore and revert”. A regra que sai dela cabe numa frase: restore mexe em arquivos, reset mexe no branch, e revert cria um commit novo.

restore: o arquivo, e só ele

O git restore devolve arquivos a um estado anterior, tirado do índice (a área de staging) ou de um commit. Segundo a documentação, ele não atualiza o branch. O histórico fica como estava.

É o comando para “estraguei este arquivo e quero a versão do último commit”:

git restore config.php

Ou para tirar um arquivo do staging sem perder o que você mudou nele:

git restore --staged config.php

Dá para buscar a versão de outro ponto da história com --source, por exemplo git restore --source main~2 Makefile. Cuidado com um detalhe: o restore sem --staged joga fora a alteração não commitada do arquivo, e ela não vai para lugar nenhum.

reset: o branch volta no tempo

O git reset move a ponta do branch. A documentação diz com todas as letras que essa operação altera o histórico de commits. É o comando para “os dois últimos commits não deviam existir”.

git reset --soft HEAD~1   # desfaz o commit, mantém as mudanças no staging
git reset HEAD~1          # desfaz o commit, mantém as mudanças nos arquivos
git reset --hard HEAD~1   # desfaz o commit e apaga as mudanças

Em commit que só existe no seu computador, o reset é perfeito. O problema começa quando o commit já foi enviado. Se outra pessoa baixou aquele histórico, você reescreve o passado que ela tem, precisa de git push --force para enviar, e o próximo pull dela vira um nó.

A regra prática: reset em commit que ainda não saiu da sua máquina.

revert: desfazer sem apagar nada

O git revert cria um commit novo, que desfaz as mudanças de um commit anterior. O erro continua no histórico, e a correção também, uma depois da outra.

git revert a1b2c3d

É o caminho certo para o que já está no repositório remoto e foi baixado pela equipe: ninguém precisa reescrever nada, e o pull dos outros funciona normal. Para desfazer um merge, o revert pede a opção -m 1, que diz qual dos pais é o lado “principal”.

Qual usar, em uma tabela

E se a senha foi parar num commit?

Aqui nenhum dos três resolve sozinho. O revert remove a senha da versão atual, mas ela continua no histórico, e qualquer um com acesso ao repositório chega nela. A primeira providência é trocar a senha. Limpar o histórico vem depois, e trocar a senha não é opcional mesmo que você limpe.

A rede de segurança que quase ninguém conhece

Fez um reset --hard e se arrependeu? Enquanto o Git não fizer a limpeza dele, os commits “apagados” continuam no repositório local, só sem um branch apontando para eles. O git reflog lista por onde a ponta do branch passou, com um código para cada posição:

git reflog
git reset --hard HEAD@{1}

O segundo comando volta o branch para a posição anterior ao último movimento. O reflog é local: ele salva o que aconteceu no seu computador, e não recupera o que outra pessoa apagou no remoto.

Para quem está começando, um seguro ainda mais barato: antes de qualquer reset que dê medo, crie um branch de backup com git branch backup-antes-do-reset. Se der errado, o estado antigo continua ali, com nome.

Fontes: Documentação do Git: Reset, restore and revert, Documentação do git restore

Produzido com auxílio de IA e revisado pela redação.