Volta uma hora atrás

O que é e porque importa

Acontece a toda a gente. Pedes uma alteração ao Claude, ele faz dez, e uma hora depois a app já não arranca. Não sabes o que ele mexeu e não te lembras de como estava antes.

O Git é a história do projeto. Sempre que guardas com um commit, tiras uma fotografia de todos os ficheiros naquele momento. Se algo se parte, voltas a uma fotografia anterior. Mas só voltas a uma fotografia que existe: se não guardaste, não há um antes para onde voltar.

Os comandos do Git não precisas de os aprender. Quem os escreve é o Claude. A ti bastam-te três frases, tal como estão, nos três momentos certos: antes de começar, quando algo se parte, antes de uma coisa grande.

Só é preciso que o projeto use Git. Se ainda não usa, pede ao Claude para o configurar: é uma linha.

1. Antes de começar: guarda

Antes de dar um trabalho ao Claude, escrevo isto:

Antes de mexeres em alguma coisa, guarda o estado atual do projeto com um commit, para podermos voltar aqui.

O Claude faz um commit: guarda o estado atual com uma mensagem que diz o que está lá dentro. Esse commit passa a ser o ponto seguro. Aconteça o que acontecer depois, podes voltar lá.

Também o faço a meio do trabalho, quando uma parte funciona. Quanto mais fotografias tiras, mais perto fica o ponto para onde podes voltar. Se o último commit é de ontem, voltar atrás quer dizer perder tudo o que fizeste hoje.

2. Quando algo se parte: volta atrás

Quando a app deixa de funcionar e não percebo porquê, não peço ao Claude para consertar o conserto do conserto. Escrevo:

Volta a como estava há uma hora. Antes guarda o que ainda não está guardado e não apagues nada do histórico: quero poder mudar de ideias.

A frase tem três partes, e cada uma conta.

• «Volta a como estava há uma hora»: o Claude olha para o histórico do projeto e procura o último commit antes desse momento. Também podes dizer «a ontem à noite» ou «a antes de mexeres no login».
• «Antes guarda o que ainda não está guardado»: as alterações que não estão num commit são as mais frágeis. O Claude põe-nas a salvo antes de mexer em alguma coisa, com um commit ou com git stash, que as põe de lado para as recuperares depois.
• «Não apagues nada do histórico»: assim o Claude usa git revert, que não apaga os commits errados, mas acrescenta um novo que os anula. O histórico fica todo lá: se percebes que uma parte do trabalho da última hora estava boa, recuperas.

O contrário é git reset --hard. Leva o projeto para trás e deita fora as alterações não guardadas nos ficheiros, sem passar pelo lixo. Às vezes é preciso, mas é o comando que faz perder trabalho. Por isso a minha frase diz «quero poder mudar de ideias».

Quando acaba, peço uma confirmação:

Diz-me a que commit voltaste, o que anulaste e corre os testes para ver se agora funciona.

3. Antes de uma coisa grande: um ramo novo

Refazer o login, mudar a base de dados, reescrever uma página inteira: são trabalhos em que as coisas podem correr mal a meio. Antes de começar, escrevo:

Faz este trabalho num ramo novo. Se funcionar e os testes passarem, junta-o ao principal. Se não funcionar, deita fora o ramo e volta ao que estava bom.

Um ramo é uma versão paralela do projeto. O Claude trabalha nele, faz os seus commits, e a versão principal, normalmente main, fica como estava. Se o trabalho funcionar, junta-o: é o merge, as alterações do ramo entram na versão principal. Se não funcionar, deita fora o ramo e voltas a estar no ponto bom.

«Os testes passam» é a parte que conta. Sem uma verificação, «funciona» só quer dizer que ao Claude parece terminado. Se o projeto não tem testes, pede-lhe pelo menos para arrancar a app e para te dizer como verificou.

Um ramo muda os ficheiros na mesma pasta do projeto, por isso um trabalho de cada vez. Se queres várias sessões do Claude em paralelo, cada uma no seu ramo, precisas dos worktrees: uma pasta separada para cada ramo. Falo disso no guia ALBERI (strikt.fit/alberi).

4. E ainda: os checkpoints do Claude Code

Além do Git há uma rede mais pequena, já dentro do Claude Code. Sempre que mandas uma mensagem, o Claude Code regista o estado dos ficheiros que o Claude altera com as suas próprias ferramentas. Estes pontos chamam-se checkpoints, e ele fá-los sozinho.

Para voltar a um destes pontos carrega duas vezes em Esc com o campo vazio, ou escreve /rewind. Se houver texto no campo, o duplo Esc só o apaga. Abre-se a lista das mensagens que mandaste: escolhes o ponto e o que restaurar.

• O código e a conversa: voltas a esse ponto com os dois.
• Só a conversa: o chat volta a essa mensagem, os ficheiros ficam como estão agora.
• Só o código: os ficheiros voltam a como estavam, a conversa fica.

As duas opções sobre o código só aparecem se, depois desse ponto, o Claude tiver alterado ficheiros.

O que não anulam

• Os comandos do terminal. Se o Claude apagar ou mover um ficheiro com rm ou mv, o rewind não o traz de volta.
• As alterações feitas fora do Claude Code: os ficheiros que mudas tu à mão no editor, ou que outra sessão muda, normalmente não são registados.

Quanto tempo duram

Os checkpoints são guardados com a conversa. Se fechares o terminal e depois retomares a mesma sessão, ainda podes fazer rewind. Mas ficam ligados a essa sessão: uma sessão nova começa sem eles. E, por predefinição, o Claude Code apaga as cópias dos ficheiros cerca de 30 dias depois, juntamente com os dados antigos da sessão.

Por isso não substituem o Git. São o botão de anular da sessão. A história verdadeira do projeto quem a guarda é o Git.

5. Uma regra de segurança

O trabalho ainda não guardado é o que podes perder de verdade, e a forma mais comum é um reset. Por isso cada frase diz ao Claude para guardar antes. Podes acrescentar:

Nunca uses git reset --hard sem me perguntar.

Se queres que valha sempre, põe-na no CLAUDE.md do projeto, o ficheiro que o Claude lê no início de cada sessão. Continua a ser uma instrução: o Claude segue-a, mas não é um bloqueio. Para um bloqueio a sério há a lista deny nas definições, que trava o comando antes de arrancar: explico-a no guia JEV (strikt.fit/jev).

Os erros mais comuns

• Trabalhar horas sem um commit: o Git só volta a gravações que existem, por isso manda guardar antes de cada trabalho e sempre que uma parte funciona.
• Mandar consertar o conserto sem fim: depois de duas tentativas falhadas, volta ao ponto bom e recomeça com um pedido mais claro.
• Contar com o rewind para tudo: não anula os comandos do terminal nem as alterações feitas fora do Claude Code, por isso a rede a sério continua a ser o Git.
• Deixar passar um git reset --hard: deita fora o trabalho não guardado, por isso pede git revert e que guarde antes.
• Fazer uma coisa grande na versão principal: começa-a num ramo novo, assim se correr mal deitas fora o ramo e não perdes nada.
• Juntar um ramo sem verificar: corre os testes antes do merge, não depois.

Checklist

• O projeto usa Git
• Commit antes de cada trabalho
• Commit quando uma parte funciona
• Para voltar atrás: git revert, nada de reset
• As coisas grandes num ramo novo
• Testes antes de juntar o ramo
• Rewind só para as alterações do Claude na sessão

Perguntas frequentes