← todos os posts
Manutenção 9 min de leitura

"Ponto de retorno: como voltar pra ontem quando a IA quebra o que funcionava (git sem virar programador)"

"Quatro comandos de git, traduzidos, pra marcar o ponto que funciona, ver o que a IA mexeu e voltar pra ele em um minuto, sem apagar nada."

"Ela conserta uma coisa e quebra outra. Você não entende o que está acontecendo porque não sabe ler o código. É como dirigir um carro sem saber abrir o capô."

A frase é de um dev brasileiro, num post de fevereiro de 2026 no TabNews sobre onde quem não programa trava com IA. E é exata. Mas eu quero mexer num pedaço dela: pra sair dessa, você não precisa aprender a abrir o capô. Precisa de uma coisa mais simples, que todo mecânico tem e quase ninguém te deu: um jeito de devolver o carro do jeito que ele entrou na oficina.

Isso tem nome, ponto de retorno, e a ferramenta que faz isso há vinte anos se chama git. Este post é o git inteiro que você precisa: quatro comandos, cada um traduzido, e a ordem de usar.

Por que ninguém te ensinou isso

Não é porque é difícil. É porque todo material de git foi escrito por dev pra dev. A documentação oficial lista dezenas de comandos, cada um com dezenas de opções, e o tutorial típico começa explicando "ramificações" e "trabalho em equipe", duas coisas que você não precisa pra voltar pra ontem. Quem desiste na terceira tela não é burro. Recebeu o manual do caminhão pra aprender a dar ré.

Tem um segundo motivo: a plataforma te deu um botão de "restaurar versão" e ele pareceu bastar. Já mostrei o que ele não restaura. E quem usa Cursor ou Claude Code também tem um "voltar" embutido. A documentação do Claude Code é honesta sobre ele: o /rewind não desfaz arquivos que a IA mexeu rodando comandos no terminal, e "não substitui controle de versão". Recomenda, com todas as letras, continuar usando git.

Pra quem é este post

Pra quem já tem o código do app na própria máquina: porque constrói com Cursor ou Claude Code, ou porque baixou do GitHub seguindo as 15 etapas. Se o seu app ainda só existe dentro do Lovable ou do Bolt, comece por lá: aquele post ensina a abrir o terminal (a janela onde você digita uma instrução e aperta Enter) e a instalar o git. Não vou repetir.

Uma regra de ouro antes de tudo: no terminal, silêncio quase sempre é sucesso. Muitos destes comandos não respondem nada quando dão certo.

Uma vez só: preparar a pasta

Abra o terminal dentro da pasta do projeto (no VS Code e no Cursor: menu Terminal → New Terminal, que já abre no lugar certo). Digite:

git --version

Tem que aparecer algo como git version 2.55.0 (a versão mais recente é de junho de 2026; qualquer uma de 2.30 pra cima serve). Agora diga ao git quem você é, porque cada ponto marcado leva uma assinatura:

git config --global user.name "Seu Nome"
git config --global user.email "[email protected]"

Se você pular isso, o primeiro ponto falha com uma mensagem pedindo exatamente essas duas linhas. É a trava número um de quem começa.

Por último, veja se a pasta já é acompanhada pelo git:

git status

Se responder fatal: not a git repository, digite git init uma vez. Se responder qualquer outra coisa, já está pronto, e você acabou de usar o primeiro comando.

Comando 1: git status — o que mudou desde o último ponto

git status

Ele lista os arquivos que foram alterados, criados ou apagados desde o último ponto marcado. Em vermelho, ou sob o título Changes not staged e Untracked files.

Você não precisa entender os arquivos. Precisa da contagem. Esse é o instinto de programador que eu disse em outro post que você não teria em três meses; o git status te dá ele de graça. Pediu pra IA trocar o texto de um botão e a lista tem nove arquivos, incluindo algo com auth (login) ou migration (mudança no banco) no nome? A IA saiu da fronteira. Você viu antes de testar, não depois do cliente reclamar.

Rode depois de toda resposta da IA. Leva dois segundos.

Comando 2: git add + git commit — marcar o ponto

São duas linhas, mas é um gesto só: tirar a foto.

git add -A
git commit -m "funciona: cadastro com CPF"

A primeira diz "tudo o que mudou entra na foto" (-A é all, tudo). A segunda tira a foto e dá um nome a ela: o texto entre aspas. Esse nome é pra você daqui a uma semana, então escreva o que funciona naquele momento, não o que você fez: "funciona: login e lista de pedidos" é melhor que "ajustes".

Quando marcar? Em dois momentos, sempre:

  1. Antes de mandar qualquer pedido pra IA. É a foto do antes. Se o pedido der errado, é pra cá que você volta.
  2. Depois de conferir que o pedido funcionou. Rode a sua bateria de testes; passou, marque.

Não deixe a IA marcar por você no começo. Ela faz, e faz bem, mas o ponto é você saber que existe um lugar seguro, com um nome que você escreveu.

Comando 3: git log --oneline — a lista dos pontos

git log --oneline

Mostra os pontos marcados, do mais novo pro mais antigo, um por linha:

a1b2c3d funciona: cadastro com CPF
9f8e7d6 funciona: login e lista de pedidos
4c5b6a7 primeira versão publicada

O código da esquerda (a1b2c3d) é a etiqueta de cada ponto. Você vai precisar dele pra voltar mais longe.

Uma armadilha: se a lista for grande, o terminal para no meio e mostra : ou (END) no rodapé, e nada que você digita parece funcionar. Não travou. Aperte q (de quit, sair).

Comando 4: git stash -u — voltar pro último ponto, sem jogar nada fora

A IA quebrou o que funcionava. Você rodou git status e viu o estrago. Agora:

git stash -u

Isso tira da frente tudo o que mudou desde o último ponto marcado, inclusive os arquivos novos que a IA criou (é o que o -u garante; sem ele, os arquivos novos ficam pra trás). O app volta a ser exatamente o da última foto.

E por que esse, e não um comando que apaga? Porque ele não apaga. A documentação oficial do git descreve assim: ele "guarda as suas modificações locais e reverte a pasta de trabalho" pro último ponto. Guarda, numa gaveta. Se você se arrepender (a mudança tinha uma parte boa, por exemplo), git stash list mostra o que está na gaveta e git stash pop traz de volta.

Pra quem não programa, isso é a diferença inteira: você pode voltar sem medo de perder, e o medo de perder é o que faz a pessoa pedir "conserta" em vez de voltar.

Depois de voltar, confira: rode o app, rode a bateria. Verde? Peça de novo, menor, com a fronteira mais apertada.

E se o erro é de três pontos atrás?

Às vezes você só descobre o estrago dias depois. Aí o último ponto também está contaminado. Três passos:

git stash -u
git restore --source=9f8e7d6 .
git add -A
git commit -m "voltei pro ponto 9f8e7d6"

O primeiro limpa a mesa, como acima. O segundo copia os arquivos de um ponto antigo (troque 9f8e7d6 pela etiqueta que você achou no git log; o ponto final no fim significa "a pasta inteira"). Pela documentação, ele também remove os arquivos que o git acompanha e que não existiam naquele ponto. O terceiro é o mesmo gesto do comando 2: marca isso como um ponto novo.

Repare: nada foi apagado do histórico. Os pontos que deram errado continuam na lista. Você só criou um ponto novo que é igual a um antigo. Se descobrir que voltou longe demais, volta de novo, pro ponto que quiser.

O que o git não volta

Três coisas, e cada uma já quebrou app de gente séria:

  1. O banco de dados. O git guarda o código, não os cadastros dos seus clientes. Se a mudança da IA alterou uma tabela, voltar o código não desfaz isso. Pergunte à IA, antes de voltar: "a última mudança alterou alguma tabela ou coluna do banco? Responda só sim ou não". O dado tem outro tipo de cópia.
  2. As chaves. O arquivo .env, com as senhas dos serviços, não deve entrar no git, e não entra se estiver no .gitignore (a lista do que o git ignora). Confira aqui. Chave que entrou num ponto marcado fica no histórico mesmo depois de apagada.
  3. O seu computador. Os pontos moram na sua máquina até você mandar pro GitHub com git push (a última das 15 etapas). Notebook roubado com pontos que nunca subiram: pontos perdidos. Faça push no fim de cada dia de trabalho.

A cola, pra colar na borda da tela

git status              o que mudou? (conte os arquivos)
git add -A
git commit -m "funciona: ..."   marcar o ponto (antes e depois de cada pedido)
git log --oneline       lista dos pontos (q pra sair)
git stash -u            voltar pro último ponto (fica na gaveta)

O que isso era, na parede inteira

Você acabou de responder "sim" à terceira pergunta do checklist de protótipo ou produto: você volta pra ontem. Pelo menos no código. E ganhou uma coisa que não está em pergunta nenhuma: a coragem de pedir a próxima mudança, porque errar passou a custar um minuto.

Ponto de retorno é o quarto item da primeira fase, a que eu chamo de Construa: código na sua máquina, banco no seu nome, teste separado do cliente, ponto de retorno. A ordem importa. Git sem o banco no seu nome volta o código e deixa os dados onde a IA deixou; banco no seu nome sem ambiente de teste faz cada experimento mexer em cadastro de cliente. É o caminho das três fases, com um portão em cada uma.

Mas hoje você não precisa do caminho inteiro. Abra o terminal na pasta do projeto, rode git status, e marque o primeiro ponto com o nome do que funciona agora. É o carro entrando na oficina com foto.

Fontes