Torna indietro di un'ora

Cos'è e perché conta

Succede a tutti. Chiedi a Claude una modifica, lui ne fa dieci, e un'ora dopo l'app non parte più. Non sai cosa ha toccato e non ti ricordi com'era prima.

Git è la storia del progetto. Ogni volta che salvi con un commit fai una foto di tutti i file in quel momento. Se qualcosa si rompe, torni a una foto di prima. Ma torni solo a una foto che esiste: se non hai salvato, non c'è un prima a cui tornare.

I comandi Git non li devi imparare. Li scrive Claude. A te bastano tre frasi, in italiano, così come sono, nei tre momenti giusti: prima di iniziare, quando qualcosa si rompe, prima di una cosa grossa.

Serve solo che il progetto usi Git. Se non lo usa ancora, chiedi a Claude di impostarlo: è una riga.

1. Prima di iniziare: salva

Prima di dare a Claude un lavoro, scrivo questo:

Prima di toccare qualcosa, salva lo stato attuale del progetto con un commit, così possiamo tornare qui.

Claude fa un commit: salva lo stato attuale con un messaggio che dice cosa c'è dentro. Quel commit diventa il punto sicuro. Qualunque cosa succeda dopo, puoi tornare lì.

Lo faccio anche a metà lavoro, quando una parte funziona. Più foto fai, più vicino è il punto a cui puoi tornare. Se l'ultimo commit è di ieri, tornare indietro vuol dire perdere tutto quello che hai fatto oggi.

2. Quando qualcosa si rompe: torna indietro

Quando l'app non va più e non capisco perché, non chiedo a Claude di riparare la riparazione della riparazione. Scrivo:

Torna a com'era un'ora fa. Prima salva quello che non è ancora salvato e non cancellare niente della storia: voglio poter cambiare idea.

La frase ha tre pezzi, e ognuno conta.

• «Torna a com'era un'ora fa»: Claude guarda la storia del progetto e cerca l'ultimo commit prima di quel momento. Puoi dire anche «a ieri sera» o «a prima che toccassi il login».
• «Prima salva quello che non è ancora salvato»: le modifiche che non sono in un commit sono le più fragili. Claude le mette al sicuro prima di muoversi, con un commit o con git stash, che le mette da parte per riprenderle dopo.
• «Non cancellare niente della storia»: così Claude usa git revert, che non cancella i commit sbagliati ma ne aggiunge uno nuovo che li annulla. La storia resta tutta lì: se ti accorgi che una parte del lavoro dell'ultima ora era buona, la recuperi.

Il contrario è git reset --hard. Riporta il progetto indietro e butta via le modifiche non salvate nei file, senza passare dal cestino. A volte serve, ma è il comando che fa perdere lavoro. Per questo nella mia frase c'è «voglio poter cambiare idea».

Quando ha finito, chiedo una conferma:

Dimmi a quale commit sei tornato, cosa hai annullato e fai girare i test per vedere se adesso funziona.

3. Prima di una cosa grossa: un ramo nuovo

Rifare il login, cambiare il database, riscrivere una pagina intera: sono lavori dove le cose possono andare storte a metà. Prima di iniziare scrivo:

Fai questo lavoro su un ramo nuovo. Se funziona e i test passano, uniscilo a quello principale. Se non funziona, butta il ramo e torna a quello buono.

Un ramo è una versione parallela del progetto. Claude ci lavora sopra, fa i suoi commit, e la versione principale, di solito main, resta com'era. Se il lavoro funziona, lo unisce: è il merge, le modifiche del ramo entrano nella versione principale. Se non funziona, butta il ramo e sei di nuovo sul punto buono.

«I test passano» è la parte che conta. Senza un controllo, «funziona» vuol dire solo che a Claude sembra finito. Se il progetto non ha test, chiedigli almeno di avviare l'app e di dirti come ha controllato.

Un ramo cambia i file nella stessa cartella del progetto, quindi un lavoro alla volta. Se vuoi più sessioni di Claude in parallelo, ognuna sul suo ramo, servono i worktree: una cartella separata per ogni ramo. Ne parlo nella guida ALBERI (strikt.fit/alberi).

4. In più: i checkpoint di Claude Code

Oltre a Git c'è una rete più piccola, già dentro Claude Code. Ogni volta che mandi un messaggio, Claude Code si segna lo stato dei file che Claude modifica con i suoi strumenti. Questi punti si chiamano checkpoint, e li fa da solo.

Per tornare a uno di questi punti premi Esc due volte con il campo vuoto, oppure scrivi /rewind. Se nel campo c'è del testo, il doppio Esc lo cancella e basta. Si apre l'elenco dei messaggi che hai mandato: scegli il punto e cosa ripristinare.

• Il codice e la conversazione: torni a quel punto con tutti e due.
• Solo la conversazione: la chat torna a quel messaggio, i file restano come sono adesso.
• Solo il codice: i file tornano com'erano, la conversazione resta.

Le due opzioni sul codice compaiono solo se dopo quel punto Claude ha modificato dei file.

Cosa non annullano

• I comandi da terminale. Se Claude cancella o sposta un file con rm o mv, il rewind non lo riporta indietro.
• Le modifiche fatte fuori da Claude Code: i file che cambi tu a mano nell'editor, o che cambia un'altra sessione, di solito non vengono tracciati.

Quanto durano

I checkpoint sono salvati con la conversazione. Se chiudi il terminale e poi riprendi la stessa sessione, puoi ancora fare rewind. Ma restano legati a quella sessione: una sessione nuova parte senza. E di default Claude Code cancella le copie dei file circa 30 giorni dopo, insieme ai dati vecchi della sessione.

Per questo non sostituiscono Git. Sono il tasto annulla della sessione. La storia vera del progetto la tiene Git.

5. Una regola di sicurezza

Il lavoro non ancora salvato è quello che puoi perdere davvero, e il modo più comune è un reset. Per questo ogni frase dice a Claude di salvare prima. Puoi aggiungere:

Non usare mai git reset --hard senza chiedermelo.

Se vuoi che valga sempre, mettila nel CLAUDE.md del progetto, il file che Claude legge all'inizio di ogni sessione. Resta un'istruzione: Claude la segue, ma non è un blocco. Per un blocco vero c'è la lista deny nelle impostazioni, che ferma il comando prima che parta: la spiego nella guida JEV (strikt.fit/jev).

Gli errori più comuni

• Lavorare ore senza un commit: Git torna solo ai salvataggi che esistono, quindi fai salvare prima di ogni lavoro e quando una parte funziona.
• Far riparare la riparazione all'infinito: dopo due tentativi a vuoto torna al punto buono e riparti con una richiesta più chiara.
• Contare sul rewind per tutto: non annulla i comandi da terminale né le modifiche fatte fuori da Claude Code, quindi la rete vera resta Git.
• Lasciar passare un git reset --hard: butta via il lavoro non salvato, quindi chiedi git revert e di salvare prima.
• Fare una cosa grossa sulla versione principale: aprila su un ramo nuovo, così se va male butti il ramo e non perdi niente.
• Unire un ramo senza controllare: fai girare i test prima del merge, non dopo.

Checklist

• Il progetto usa Git
• Commit prima di ogni lavoro
• Commit quando una parte funziona
• Per tornare indietro: git revert, niente reset
• Le cose grosse su un ramo nuovo
• Test prima di unire il ramo
• Rewind solo per le modifiche di Claude nella sessione

Domande frequenti