Git revert, reset e restore: o que usar para desfazer alterações sem perder trabalho

Publicado em 2026-10-26 por frfrand

Escolher entre reverter um commit, mover o HEAD ou recuperar um arquivo

Git revert, reset e restore: o que usar para desfazer alterações sem perder trabalho

Três comandos para «desfazer» que não fazem a mesma coisa. Escolher errado pode apagar alterações locais ou reescrever um branch que outras pessoas já usam. Convém conhecer a diferença antes de copiar uma ordem com --hard.

A ideia é usá-lo para resolver um problema de verdade, não memorizar comandos porque ficam bem em uma captura. Vamos com o essencial, um exemplo de trabalho e os erros que mais convém evitar.

O que fazem Git revert, reset e restore e quando servem

git revert cria um commit que inverte o efeito de outro: é apropriado para alterações já compartilhadas. git reset move a referência do branch e pode alterar índice e arquivos; --hard descarta trabalho não confirmado. git restore recupera arquivos do índice ou uma revisão conforme as opções.

Se está aprendendo, teste primeiro em um repositório ou ambiente de teste. Se administra produção, documente o estado antes de executar qualquer coisa que altere arquivos, histórico ou dados. Isso permite entender o que mudou e recuperar-se se errar.

Exemplo para copiar e entender

# Deshacer un commit publicado sin reescribir historial
git revert abc1234
# Ver el estado antes de tocar archivos
git status
git diff
# Recuperar UN archivo modificado localmente
git restore -- ruta/al/archivo.py
# Mover HEAD conservando cambios en staging
git reset --soft HEAD~1

Não copie a ordem final sem olhar o estado prévio. Os nomes de branches, host, usuário ou caminhos são exemplos; substitua-os pelos do seu projeto. Alguns comandos modificam arquivos ou fazem requisições que podem gravar dados.

Como usaria passo a passo

Passo 1. Se o commit já está em um branch compartilhado, prefira revert e revise os possíveis conflitos.
Passo 2. Para um arquivo local que você deseja descartar, inspecione primeiro git diff.
Passo 3. Para corrigir um commit ainda não publicado, avalie reset --soft ou --mixed de acordo com se você deseja manter o staging.
Passo 4. Evite reset --hard se você não estiver absolutamente seguro de que essas mudanças podem ser perdidas.
Passo 5. Antes de implantar a reversão, execute os testes e verifique as migrações de banco de dados.

Pare após cada passo e verifique o resultado. Se algo falhar, anote a mensagem exata antes de mudar de estratégia. Pular entre cinco soluções aleatórias costuma dificultar encontrar a causa real.

Um caso que pode acontecer trabalhando com clientes

É publicada uma alteração de preço incorreta em um site. Em main compartilhado, convém criar um revert rastreável, não enviar um reset forçado que mova o histórico de todos.

O objetivo não é que «funcione uma vez», mas que você possa explicar como repete sem comprometer outra aplicação. Se houver dados ou credenciais de clientes, trabalhe com testes separados e acessos mínimos.

O erro que mais vejo

Reverter código não reverte uma migração do PostgreSQL nem uma operação de dados. Se a implantação modificou o esquema, você precisa de um plano específico para compatibilidade e recuperação.

Uma regra simples: se você não puder explicar o que o comando fará no seu código ou servidor, consulte primeiro a ajuda oficial. Assim, você evita confundir uma solução rápida com um novo problema.

Onde entra o ArduMaker?

Com o deploy Git do ArduMaker, manter o hash de cada versão permite associar um erro a um commit. Mas a reversão da base e dos arquivos persistentes deve ser projetada à parte.

Por exemplo, você pode fazer deploy de um repositório Git para um VPS, associar um domínio HTTPS e gerenciar serviços e bancos de dados no mesmo ambiente. O painel reduz tarefas repetitivas de infraestrutura, mas não substitui o Git, os testes nem a revisão de permissões do projeto.

Perguntas rápidas antes de aplicá-lo

Isso altera a produção? Depende de onde você executa a ação. Teste localmente primeiro, identifique o commit ou serviço afetado e prepare um plano de recuperação.

Como comprovar que deu certo? Não fique apenas com a ausência de mensagens de erro: verifique o status, execute um teste funcional e confira os logs ou o histórico correspondente.

Vale a pena automatizar? Se for repetível e tiver resultados verificáveis, sim. Mas a automação deve falhar de forma clara e não esconder erros ou credenciais.

Para ampliar

Resumo: a ferramenta útil não é a que tem mais opções, mas sim a que permite entender o que mudou, comprovar isso e continuar trabalhando sem surpresas.