Como Desfazer Erros no Git com Segurança: Revert, Reset e Checkout Explicados
Navegue pelos erros do Git com confiança! Este guia explica `git revert`, `git reset` e `git checkout` para desfazer commits com segurança, restaurar arquivos e gerenciar o histórico do seu repositório. Aprenda quando e como usar cada comando para corrigir erros sem perder trabalho valioso, tornando-o leitura essencial para qualquer usuário de Git.
Como Desfazer Erros no Git com Segurança: Revert, Reset e Checkout Explicados
Os erros no Git geralmente parecem piores do que realmente são. Você pode ter commitado o arquivo errado, adicionado muitos arquivos à área de staging ou enviado uma alteração ruim para um branch compartilhado. A correção segura depende de uma pergunta: a alteração já foi compartilhada?
Este guia explica quando usar git revert, git reset e git checkout, com exemplos que você pode copiar com cuidado. A versão resumida é simples: use git revert para commits compartilhados, git reset para limpeza local e git checkout apenas quando quiser trocar de branch ou restaurar estados antigos de arquivos.
Primeiro, Verifique o Que Você Está Prestes a Desfazer
Antes de executar qualquer comando de desfazer, veja seu estado atual:
git status
git log --oneline --decorate -5
git status informa se você tem trabalho não preparado, preparado ou não rastreado. git log mostra os commits recentes e para onde seu branch aponta.
Se você tem trabalho local que não quer perder, crie um branch de segurança rápido primeiro:
git branch backup-antes-de-desfazer
Esse branch oferece um caminho fácil de volta se você escolher o comando errado.
Use git revert para Commits Já Enviados
git revert cria um novo commit que aplica o oposto de um commit anterior. Ele não exclui o histórico, então é a escolha mais segura para branches compartilhados como main, develop ou qualquer branch que outras pessoas possam ter puxado.
Suponha que seu histórico se pareça com isso:
A -- B -- C -- D main
O commit C introduziu um bug, mas D é bom e deve permanecer. Encontre o hash do commit:
git log --oneline
Em seguida, reverta apenas esse commit:
git revert abcdef1
O Git abre seu editor para a mensagem do commit de reversão. Depois de salvá-la, o histórico fica assim:
A -- B -- C -- D -- E main
O commit E desfaz as alterações de C. Todos podem puxar esse novo commit normalmente.
Revertendo um Commit de Merge
Commits de merge precisam de uma flag extra porque o Git precisa saber qual pai é a linha principal:
git revert -m 1 <hash-do-commit-de-merge>
Para um merge normal em main, -m 1 geralmente significa "manter o primeiro pai", que é o branch no qual você fez o merge. Não adivinhe aqui. Execute isso primeiro e inspecione os pais:
git show --summary <hash-do-commit-de-merge>
Se você não tem certeza de qual pai manter, pergunte a um colega de equipe ou teste a reversão em um branch temporário.
Use git reset para Commits Locais
git reset move o ponteiro do seu branch atual. Dependendo do modo, ele também pode alterar a área de staging e seus arquivos de trabalho. Use-o principalmente para commits que você não enviou.
Remover um Arquivo da Área de Staging
Se você adicionou o arquivo errado à área de staging, remova-o sem alterar o conteúdo do arquivo:
git restore --staged arquivo_indesejado.txt
Exemplos mais antigos do Git costumam usar este comando equivalente:
git reset HEAD arquivo_indesejado.txt
Ambos removem o arquivo da área de staging. Suas edições permanecem no diretório de trabalho.
Desfazer o Último Commit, mas Manter as Alterações na Área de Staging
Use --soft quando a mensagem do commit estiver errada ou você quiser adicionar mais um arquivo antes de recommitar:
git reset --soft HEAD~1
Seu branch volta um commit, mas as alterações desse commit permanecem na área de staging.
Desfazer o Último Commit e Manter as Alterações Fora da Área de Staging
Use o reset misto padrão quando quiser retrabalhar os arquivos antes de commitar novamente:
git reset HEAD~1
Isso move o branch um commit para trás e deixa as alterações no seu diretório de trabalho.
Descartar Commits Locais e Alterações em Arquivos
--hard redefine o branch, a área de staging e os arquivos rastreados no seu diretório de trabalho:
git reset --hard HEAD~1
Use isso apenas quando tiver certeza de que não precisa das alterações descartadas. Ele não remove arquivos não rastreados, mas descartará edições em arquivos rastreados sem perguntar novamente.
Use git checkout com Cuidado
git checkout tem duas funções comuns em fluxos de trabalho Git antigos: trocar de branch e restaurar arquivos. Versões mais novas do Git dividem essas funções em comandos mais claros: git switch para branches e git restore para arquivos.
Para trocar de branch:
git switch main
Equivalente antigo:
git checkout main
Para descartar alterações não commitadas em um arquivo rastreado:
git restore meu_arquivo.txt
Equivalente antigo:
git checkout -- meu_arquivo.txt
Essa restauração de arquivo é destrutiva para edições não commitadas no arquivo selecionado. Se você pode precisar das edições depois, faça stash delas primeiro:
git stash push -m "salvar trabalho antes de restaurar"
Use git reflog Se Você Foi Longe Demais
Se você executou git reset --hard ou moveu um branch por engano, git reflog ainda pode mostrar para onde HEAD apontava antes:
git reflog
Você pode ver uma entrada anterior como HEAD@{2} ou um hash de commit de antes do reset. Você pode criar um branch de recuperação a partir dele:
git branch recuperacao <hash-do-commit>
Reflog é local ao seu clone e não é um sistema de backup, mas muitas vezes salva você de erros recentes.
Qual Comando Você Deve Escolher?
Use git revert quando o commit ruim já foi enviado ou outras pessoas podem ter baseado trabalho nele.
Use git reset --soft quando seu último commit local deve ser refeito, mas as alterações ainda estão corretas.
Use git reset quando você quiser que o último commit local volte como alterações de arquivo não preparadas.
Use git reset --hard apenas quando alterações locais rastreadas puderem ser excluídas.
Use git restore ou git checkout -- <arquivo> quando quiser descartar alterações não commitadas em arquivos específicos.
O hábito mais seguro é verificar git status, criar um branch de backup temporário quando o risco for alto e evitar reescrever o histórico compartilhado. Se um commit chegou a um repositório remoto compartilhado, git revert geralmente é a correção mais limpa.