# Come annullare le modifiche in Claude Code: /rewind e git > Modalità di ripristino, limiti dei checkpoint, git checkout, stash, reflog e protezione dai comandi distruttivi. Cinque modi per ripristinare uno stato. Source: https://ailoot.ai/blog/it/claude-code-undo-changes/ Canonical: https://ailoot.ai/blog/it/claude-code-undo-changes/ Language: it Publisher: Ailoot (https://ailoot.ai/) Translation: guide-138 Revision: sha256-d538309cf6ebac894ee0b25a137a7d0033d2e130102cdca05e71952b598f14c5 [Informazioni pratiche su come lavorare con Ailoot sono disponibili nella documentazione](https://ailoot.ai/docs/). ## Che cos'è l'annullamento in Claude Code e perché tre livelli non bastano?
Punti chiave L'annullamento in Claude Code ha tre livelli: il comando integrato `/rewind` (ripristino immediato all'interno di una sessione), `git checkout` (ripristino all'ultimo commit) e `git reflog` (rete di sicurezza in caso di emergenza, se qualcuno ha eseguito `git reset --hard`). Ogni livello copre una propria classe di errori e nulla oltre i suoi limiti. Conoscere solo `/rewind` significa restare scoperti al primo errore serio.
Ho attivato `/rewind` nella mia prima settimana di utilizzo di Claude Code, quando ha mandato in crisi la logica di autenticazione del mio progetto in due prompt. Ho ripristinato, tirato un sospiro di sollievo e continuato. Un mese dopo si è presentata un'altra situazione: stavo scrivendo una migrazione dello schema, Claude mi ha aiutato, ho fatto un commit, sono passato a un altro branch e mi sono reso conto di aver dimenticato un passaggio necessario. `/rewind` non è servito: la sessione era già diversa. È stato utile `git checkout` al commit precedente. Un mese più tardi, ho detto per sbaglio all'agente: «riporta tutto all'ultimo push», e lui ha eseguito `git reset --hard`, mandando in fumo tre ore di lavoro. `git reflog` mi ha salvato: gli hash dei commit distrutti erano ancora lì. Queste tre storie rappresentano tre livelli di protezione che funzionano in modo diverso, intercettano errori diversi e servono tutti. Questa guida spiega ogni livello, con i relativi comandi, limiti ed esempi, e mostra anche come configurare un progetto in anticipo affinché Claude non lo metta a terra la prima volta. **3 livelli di annullamento: cosa fanno e quando usarli:** | Livello | Comando | Copre | NON copre | |----|----|----|----| | 1\. All'interno di una sessione | `/rewind` o `Esc Esc` | File modificati da Claude tramite i suoi strumenti; cronologia della conversazione | Comandi Bash, editor esterni, migrazioni del database | | 2\. Prima di un commit | `git checkout .` o `git stash` | Tutte le modifiche non sottoposte a commit ai file | Commit già eseguiti | | 3\. Emergenza | `git reflog` + `git reset --hard ` | Commit distrutti da `reset --hard` o force-push | Comandi Bash distruttivi (rm, migrazioni del database) | Ora vedremo ogni livello: cosa fare esattamente, le insidie e come configurare tutto affinché non ci sia nulla da annullare perché nulla si è rotto. ## Come si richiama /rewind: con un comando o con Esc-Esc?
Punti chiave Ci sono due modi per aprire il menu Rewind in Claude Code. Il primo è digitare `/rewind` nel campo di input. Il secondo è premere `Esc` due volte quando il campo di input è vuoto. Se nel campo c'è del testo, il doppio Esc prima lo cancella e ne salva il contenuto nella cronologia dell'input; un altro doppio tocco apre il menu. Il comando `/rewind` ha come alias `/checkpoint`.
Dopo ogni risposta, Claude crea automaticamente uno snapshot di tutti i file modificati in quella sessione. Gli snapshot sono archiviati in `~/.claude/file-history/{sessionId}/` e conservati fino a 30 giorni. Sono incrementali: vengono salvate solo le differenze tra gli stati, non l'intero file. Per impostazione predefinita, ogni sessione conserva fino a 100 snapshot. Questo significa che, nella maggior parte dei progetti reali, in qualsiasi momento hai una cronologia completa di tutte le modifiche apportate da Claude durante la giornata di lavoro. Per aprire il menu di ripristino, premi `Esc` due volte quando il campo di input è vuoto: ``` [user-input is empty] > _ [press Esc, Esc] Rewind to which message? 1. Create a migration for the User table (3 files changed) 2. Add the lastLoginAt field (1 file changed) 3. Rewrite the authorization logic (5 files changed) ... ``` Se nel campo di input c'è del testo, il primo doppio tocco di `Esc` lo cancella e lo salva nella cronologia accessibile con `Up`. È utile quando hai già iniziato a digitare e ti rendi conto che devi ripristinare. Ecco una citazione dalla documentazione ufficiale di Anthropic:

Se c'è del testo nel campo del prompt, il doppio Esc prima lo cancella, invece di aprire il menu. Il testo cancellato viene salvato nella cronologia dell'input, così puoi ripristinarlo con la freccia su dopo il menu di ripristino.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Il comando `/rewind` fa la stessa cosa: apre il menu. C'è un alias, `/checkpoint`, che porta allo stesso menu. Quale metodo sia più comodo dipende dall'abitudine. Io uso `Esc Esc`: è più veloce e non devo staccare le mani dalla tastiera. ## 6 modalità nel menu Rewind: quale scegliere e quando?
Punti chiave Dopo aver selezionato un punto di ripristino nel menu Rewind, appare un secondo menu con sei modalità. Tre ripristinano lo stato (`Restore code and conversation`, `Restore conversation`, `Restore code`), due comprimono la cronologia (`Summarize from here`, `Summarize up to here`) e una annulla l'azione (`Never mind`). Lo scenario più comune, «ripristinare sia il codice sia la conversazione», corrisponde alla prima opzione.
Scegli un punto nell'elenco e arriverai al menu delle azioni. Sei voci, ognuna fa qualcosa di diverso. **Tabella completa delle modalità:** | Modalità | Cosa fa | Quando sceglierla | |----|----|----| | `Restore code and conversation` | Ripristina sia i file sia la cronologia della conversazione al punto selezionato | Lo scenario più comune: Claude ha preso la direzione sbagliata e voglio ricominciare con una formulazione corretta | | `Restore conversation` | Ripristina solo la cronologia della conversazione; i file restano come sono adesso | Il codice va bene, ma la conversazione è uscita dai binari; riformulerò da questo punto mantenendo le modifiche attuali | | `Restore code` | Ripristina i file; la conversazione resta com'è | Alcune modifiche di Claude erano superflue, ma mi serve ancora il contesto della conversazione (per esempio, avevamo concordato i prossimi passi) | | `Summarize from here` | Comprimi tutto ciò che viene DOPO il punto selezionato in un riepilogo. Non modifica i file | Una lunga sessione di debug ha esaurito il contesto; devo liberare spazio mantenendo intatte le istruzioni iniziali | | `Summarize up to here` | Comprimi tutto ciò che viene PRIMA del punto selezionato in un riepilogo. Non modifica i file | C'è stato un lungo briefing iniziale seguito da un compito specifico: comprimiamo il briefing in un messaggio e lasciamo invariato il lavoro recente | | `Never mind` | Chiude il menu senza apportare modifiche | Ho cambiato idea | La funzione `Summarize up to here` è apparsa in Claude Code v2.1.139-v2.1.142, rilasciata dall'11 al 15 maggio 2026, nella settimana 20:

Puoi comprimere il contesto iniziale attraverso il menu Rewind usando 'Summarize up to here'.

— Anthropic What's new, https://code.claude.com/docs/en/whats-new
La differenza tra `Restore` e `Summarize` è fondamentale. Restore riporta a uno stato precedente, annullando tutto ciò che è successo dopo il punto selezionato. Summarize non annulla nulla: comprime soltanto; i messaggi originali restano nella trascrizione della sessione come riferimento, ma nel contesto attivo rimane solo il riepilogo. Usa restore quando vuoi che sia «come se non fosse mai successo». Usa summarize quando vuoi «conservarlo senza occupare spazio nel contesto». Dopo `Restore conversation` o `Summarize from here`, il testo originale del prompt selezionato torna nel campo di input: puoi modificarlo e inviarlo di nuovo. Dopo `Summarize up to here`, il campo di input è vuoto e resti alla fine della conversazione. ## Quali modifiche NON annulla /rewind?
Punti chiave `/rewind` tiene traccia solo delle modifiche apportate da Claude tramite i propri strumenti di modifica dei file. Non può vedere o ripristinare altro. Ci sono tre classi di modifiche invisibili: i comandi Bash (rm, mv, cp), le modifiche esterne (le tue modifiche manuali in un IDE, le modifiche da altre sessioni) e le operazioni che non riguardano i file (migrazioni del database, git push, chiamate API remote).
È il limite principale in cui ci si imbatte: `/rewind` mostra un segno di spunta verde e dice «ripristino riuscito», ma il progetto è ancora rotto perché Claude ha modificato più dei soli file. Vediamo i tre casi. **1. I comandi Bash non sono tracciati.** Se Claude esegue `rm file.txt` o `mv old.txt new.txt` durante un turno, quelle modifiche non saranno incluse nel checkpoint. La documentazione di Anthropic afferma esplicitamente:

Il checkpointing non tiene traccia dei file modificati tramite comandi Bash. Per esempio, se Claude Code esegue rm file.txt, mv old.txt new.txt, cp source.txt dest.txt, queste modifiche ai file non possono essere annullate tramite il ripristino.

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Questo significa che se Claude elimina, sposta o copia un file usando autonomamente lo strumento Bash, `/rewind` non ripristinerà tutto. Può essere utile `git checkout` o il ripristino da un backup, ma serve più di una pressione di due tasti. **2. Le modifiche esterne non vengono intercettate.** Se apri manualmente un file in VS Code e lo modifichi, oppure una seconda sessione di Claude modifica gli stessi file in parallelo, la prima sessione non può vedere quelle modifiche. Uno snapshot del checkpoint viene acquisito quando Claude termina un turno nella sessione corrente. Ciò che accade tra un turno e l'altro esula dalla sua responsabilità. **3. Le operazioni che non riguardano i file non sono coperte affatto.** Una migrazione Prisma applicata tramite `npx prisma migrate dev` ha modificato lo schema del database: `/rewind` non la annullerà, perché il database è al di fuori del file system del progetto. Vale lo stesso per un force-push a `origin/main`: il commit è finito sul server remoto e il checkpoint non lo recupererà. Una chiamata API remota che ha addebitato denaro o eliminato un record può essere annullata solo tramite i meccanismi dell'API stessa. **Regola:** se un'attività riguarda qualcosa al di fuori dei file del progetto — migrazioni del database, git push, API remote — prepara una strategia di rollback separata per ogni effetto esterno. `/rewind` è solo la cronologia locale dei file all'interno della sessione corrente. ## /rewind e git: in cosa differiscono e perché servono entrambi?
Punti chiave `/rewind` è un rollback locale all'interno di una singola sessione di Claude Code. Memorizza snapshot incrementali per un massimo di 30 giorni, fino a 100 per sessione. git è la cronologia a lungo termine del progetto, condivisa con il team, con branch, conflitti di merge e un repository remoto. Uno non sostituisce l'altro. La prassi migliore è creare un `git commit` a ogni traguardo logico e affidarsi a `/rewind` tra un commit e l'altro.
La documentazione di Anthropic descrive direttamente questo abbinamento:

I checkpoint sono progettati per un rapido ripristino a livello di sessione. Per commit, branch e cronologia a lungo termine, continua a usare un sistema di controllo versione (per esempio, Git). I checkpoint affiancano il normale controllo versione, ma non lo sostituiscono. Pensa ai checkpoint come ad «annullamento locale» e a Git come alla «cronologia permanente».

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Le differenze in una tabella: | Parametro | /rewind | git | |----|----|----| | Granularità | Ogni turno della conversazione | Ogni commit | | Archiviazione | Fino a 30 giorni, fino a 100 per sessione, in locale in `~/.claude/file-history/` | In modo permanente, nel `.git/` del repository e sul server remoto | | Cosa traccia | Le modifiche di Claude tramite i suoi strumenti | Tutte le modifiche sottoposte a commit | | Cosa NON traccia | Bash, modifiche esterne, migrazioni, push | Modifiche non sottoposte a commit | | Comando | Un comando all'interno di Claude | Un sistema esterno di controllo versione | | Ripristina la conversazione | Sì | No | | Funziona tra sessioni | Solo all'interno della stessa sessione | Ovunque | L'abbinamento è semplice: ogni volta che raggiungi uno stato in cui «funziona e non voglio perderlo», crea un `git commit`. Tra un commit e l'altro, affidati a `/rewind`: è immediato, non richiede un messaggio di commit e non ingombra la cronologia git con stati intermedi. Quando il lavoro è concluso, fai un commit, preferibilmente significativo e atomico. ## Perché un solo /rewind non copre l'intero compito? L'annullamento è un caso di **ingegneria del contesto**. Gestisci il contesto della sessione (quando fare un commit, quando premere `/rewind`, quali regole inserire in `CLAUDE.md`) e otterrai un Claude prevedibile, che non distrugge il progetto né perde il lavoro. ## Perché `git reset --hard` è pericoloso quando chiedi a Claude di «tornare indietro»?
Punti chiave Nel linguaggio naturale, «tornare indietro» significa «guardare la cronologia», non «distruggerla»; Claude dovrebbe proporre `git checkout` per impostazione predefinita, non `reset --hard`; la protezione si configura in CLAUDE.md.
Una richiesta di «salvare lo stato attuale e tornare all'ultimo push» può portare a questi comandi: ```bash git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix" # saved uncommitted changes git reset --hard 35eb731 # destroyed commits d63695e..882e618 ``` Il primo comando era corretto: ha salvato nello stash le modifiche non sottoposte a commit. Il secondo era distruttivo: ha riportato il branch al commit `35eb731` e tutti i commit tra questo e `882e618` sono diventati orfani. Per impostazione predefinita, i commit orfani restano in `.git/objects/` fino all'esecuzione di `git gc`, che di solito avviene automaticamente entro due settimane. Ma se in quel momento non sapevi cosa fare, il tempo stava già giocando contro di te. La logica è semplice: nel linguaggio naturale, «tornare indietro», «andare indietro», «ripristinare», «revertire» e «annullare» significano «guardare indietro» o «tornare in un luogo sicuro». Non significano «distruggere la cronologia». Il comando `git reset --hard` la distrugge: riscrive il branch e rimuove i commit che non sono più raggiungibili da HEAD. Un'alternativa sicura è `git checkout `, che crea un HEAD scollegato e permette di visualizzare lo stato precedente senza toccare i branch. La principale indicazione pratica è fare un `git commit` dello stato corrente prima di qualsiasi attività sostanziale, soprattutto prima di rifattorizzare più file. Un commit trasforma qualsiasi pasticcio di Claude in un singolo comando `git checkout .`, senza perdere il lavoro. ## Come ti salva git reflog dopo un reset distruttivo?
Punti chiave `git reflog` mostra la cronologia locale di tutti gli spostamenti di HEAD nel repository, compresi i commit rimossi tramite `git reset --hard` o force-push. Ogni spostamento è conservato per 90 giorni per impostazione predefinita. Se Claude (o tu, o qualcun altro) ha distrutto dei commit con un comando distruttivo, `git reflog` ne mostrerà gli hash e potrai ripristinare il branch con `git reset --hard `.
Dopo un reset distruttivo, esegui subito `git reflog`: ```bash git reflog ``` L'output è simile a questo: ``` 35eb731 HEAD@{0}: reset: moving to 35eb731 882e618 HEAD@{1}: commit: middleware refactoring complete d63695e HEAD@{2}: commit: leaveRemove method finalized 1f9c8a3 HEAD@{3}: commit: tracker enter/leave disabled 35eb731 HEAD@{4}: pull origin main ``` `HEAD@{1}` fino a `HEAD@{3}` sono proprio quei commit «distrutti». Non sono scomparsi dall'archivio locale degli oggetti di git: sono semplicemente diventati irraggiungibili attraverso il branch. Per ripristinarli: ```bash # Create a branch from the last “destroyed” commit git branch recovered-work 882e618 # Or switch directly git reset --hard 882e618 ``` Dopodiché, il branch conterrà di nuovo tutta la cronologia fino al disastro. **Limiti di reflog:** 1. **Solo in locale.** Il reflog è archiviato in `.git/logs/HEAD`; non si trova nel repository remoto. Se fai un force-push e poi elimini la copia locale del repository, il reflog sparisce con la cartella. 2. **90 giorni per impostazione predefinita.** Le voci più vecchie possono essere rimosse da git gc. Puoi configurarlo con `git config gc.reflogExpire 200.days.ago`. 3. **Non copre ciò che non è mai stato in HEAD.** Se un commit era solo nello stash e lo stash è stato distrutto, il reflog mostrerà soltanto lo stato più recente dello stash, non la sua cronologia interna. **Regola per il team:** non eseguire mai `git gc --aggressive` subito dopo un disastro. Prima fai un'indagine con reflog e recupera; a tutto il resto pensa dopo. E non eliminare mai il clone locale del repository finché non sei sicuro che tutto ciò che ti serve sia stato sottoposto a push. ## Come si protegge un progetto dai comandi git distruttivi tramite CLAUDE.md?
Punti chiave Nel file `CLAUDE.md` del progetto, aggiungi un blocco di istruzioni che definisca quali comandi git Claude può eseguire da solo, quali richiedono conferma esplicita e quali sono vietati senza una frase esatta dell'utente. Claude tratta CLAUDE.md come prompt di sistema del progetto e segue queste regole per impostazione predefinita. In questo modo, un singolo prompt «pericoloso» si trasforma in due comandi sicuri.
La vulnerabilità è che Claude non dispone di un contesto protettivo per impostazione predefinita. Interpreta «tornare indietro» come `git reset --hard` perché tecnicamente è un metodo valido. Inserisci la protezione in `CLAUDE.md`, il file del prompt di sistema del progetto. **Regola minima** (da inserire nel tuo `CLAUDE.md`): ```markdown ## Protocollo di sicurezza Git - NON eseguire MAI comandi git distruttivi (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) a meno che non richieda esplicitamente queste azioni. Le azioni distruttive non autorizzate sono inutili e possono causare la perdita del lavoro. - Quando dico "roll back", "go back", "restore", "revert", "undo", interpretalo come comandi di VERIFICA: usa `git log`, `git diff`, `git checkout ` (crea un HEAD scollegato) oppure `git stash` (conserva le modifiche). - Chiedimi SEMPRE conferma prima di QUALSIASI comando che: - Cambia la posizione di HEAD portandolo a un commit diverso su un branch - Modifica la cronologia dei commit - Potrebbe causare la perdita di lavoro non sottoposto a commit - Include i flag --hard, --force, --aggressive - Prima di qualsiasi comando distruttivo, mostra un confronto numerato: - SICURO: usa `git checkout ` per visualizzare temporaneamente - DISTRUTTIVO: usa `git reset --hard` per distruggere definitivamente - Attendi la mia scelta esplicita prima di eseguire. ``` **Regola estesa** per il team (da aggiungere al `CLAUDE.md` nella radice del repository): ```markdown ## Regole del flusso di lavoro Git - Esegui un commit a ogni traguardo funzionante. Prima di un commit WIP, usa `git status` e `git diff`, aggiungi solo file nominati esplicitamente e revisionati con `git add -- path/to/file`, poi controlla il diff in staging. Il timer ricorda di revisionare, non autorizza a includere l’intero albero di lavoro. - Claude non deve mai usare `git add .` o `git add -A` per i commit. Specifica solo i file per nome, dopo `git status` + `git diff`. - Prima di `git push --force` su main, fermati e chiedimelo. Nei branch delle funzionalità, usa force-push con cautela, solo se sei sicuro che io sia disposto a perdere la versione precedente. - Quando risolvi conflitti di merge, non scegliere subito "ours" o "theirs": mostrami prima entrambe le versioni, poi deciderò. - `.gitignore` deve contenere `.env*`, `.claude/personal/`, `node_modules/`, `dist/`. Se mancano, aggiungile. ``` Dopo aver aggiunto questi blocchi, la frase «torna all'ultimo push» porterebbe alla risposta seguente: > Vedo 3 file non sottoposti a commit e 4 commit successivi all'ultimo push. Due opzioni: > > 1. SICURO: creare un branch `view-last-push` tramite `git checkout `: conserverò tutto il lavoro, ma mostrerò temporaneamente lo stato del push. > 2. DISTRUTTIVO: `git reset --hard `: distruggerò definitivamente 4 commit e le modifiche non sottoposte a commit. Potranno essere recuperati solo tramite `git reflog` entro 90 giorni. Quale scegli? È mezzo minuto di conversazione invece di quattro ore di lavoro perso. ## Quali sono i 5 modi per annullare in Claude Code e come si sceglie quello giusto?
Punti chiave Se qualcosa va storto, ci sono cinque livelli di emergenza: `/rewind` (all'interno di una sessione), `git checkout .` (modifiche non sottoposte a commit), `git checkout ` (tornare a un vecchio commit senza perdere la cronologia), `git reset --hard ` (riportare indietro il branch, perdendo i commit successivi a quel punto), `git reflog` + recupero (disastro: è sparito tutto). Ogni livello è più impegnativo e pericoloso del precedente.
Lo scenario «Claude ha rotto tutto, devo ripristinarlo con urgenza» va affrontato dal basso verso l'alto lungo questa scala. Inizia sempre dal livello 1. **Livello 1. `/rewind`: annullamento immediato all'interno di una sessione.** Premi `Esc Esc` oppure digita `/rewind`. Scegli il punto precedente al problema. Scegli una modalità (di solito `Restore code and conversation`). Un secondo dopo sei tornato indietro e puoi ricominciare. Copre l'80% dei casi in cui «Claude ha fatto la cosa sbagliata». **Livello 2. `git checkout .`: annulla tutte le modifiche non sottoposte a commit.** ```bash git diff # first see what actually changed git checkout . # undo all uncommitted changes in all files # or selectively: git checkout -- path/to/file.ts # only one file ``` Utile quando `/rewind` non ha funzionato (per esempio, Claude ha toccato file tramite Bash) o quando devi annullare modifiche fuori dalla cronologia della sessione. Tutte le modifiche non sottoposte a commit spariranno definitivamente. Se potresti pentirtene, esegui prima `git stash` (vedi il livello 2.5). **Livello 2.5. `git stash`: metti da parte le modifiche.** ```bash git stash save "might still need this" # return to a clean state (without changes) # ... # if you change your mind—restore from stash: git stash pop ``` Un buon compromesso tra «perdere per sempre» e «lasciare tutto com'è». Lo stash resta in locale finché non viene eliminato esplicitamente. **Livello 3. `git checkout `: torna a un vecchio commit senza perdere la cronologia.** ```bash git log --oneline # find the hash of the right commit, e.g. abc1234 git checkout abc1234 # detached HEAD—view without changing anything # like the state? create a branch from it: git checkout -b recovery abc1234 # return: git checkout main ``` È un «ritorno temporaneo» sicuro. Il HEAD scollegato non modifica il branch: il lavoro corrente in `main` (o in qualunque branch ti trovassi) resta intatto. Se vuoi lavorare in questo stato, crea un branch. **Livello 4. `git reset --hard `: riporta il branch a un punto precedente.** ⚠️ Distruttivo. I commit successivi all'hash specificato diventano orfani. ```bash git reflog # note the hash of the current state git reset --hard abc1234 # rewrite the branch # found a mistake? return through reflog: git reset --hard HEAD@{1} # to where you were before the reset ``` Usalo solo se sei certo che non ti servano i commit successivi. E controlla sempre `git reflog` PRIMA del reset, per sapere dove tornare se cambi idea. **Livello 5. `git reflog` + recupero: scenario catastrofico.** Qualcuno (Claude, tu, un collega) ha già eseguito `git reset --hard` o force-push e ha cancellato il lavoro. Che cosa fai? ```bash git reflog # look for the last hash before the disaster git branch recovered HEAD@{N} # create a branch from it git checkout recovered # switch to it git diff main # compare with the current state git checkout main && git merge recovered # restore into main, if you're sure ``` Se il reflog è già stato cancellato (dopo 90 giorni per impostazione predefinita), l'ultima risorsa è `git fsck --lost-found`, che mostrerà i commit non raggiungibili in `.git/objects/`. È quasi un lavoro di archeologia, ma a volte funziona. **Regola per scegliere un livello:** | Che cosa è successo | Livello | |-----------------------------------------------|-----------------------------| | Claude ha riscritto male 3 file | 1\. `/rewind` | | Ci ho provato, non mi è piaciuto e la sessione non aiuta | 2\. `git checkout .` | | Ho fatto danni manualmente, non voglio perderli e potrei ripristinarli | 2.5. `git stash` | | Ho fatto un commit; devo tornare indietro di un commit | 3\. `git checkout ` | | Sono certo che non mi servano i commit successivi | 4\. `git reset --hard` | | Ho già cancellato tutto con un comando distruttivo | 5\. `git reflog` | ## Come proteggere un progetto affinché non ci sia nulla da annullare?
Punti chiave Il miglior annullamento è quello che non serve. Tre regole di protezione: rivedi i progressi ogni 30 minuti e registra un traguardo funzionante aggiungendo esplicitamente soltanto percorsi revisionati; inserisci le righe `.claude/personal/` e `.env*` richieste nel `.gitignore`; fai gli esperimenti più impegnativi in un branch separato con `git checkout -b experiment-`. Questo riduce l’intervallo di recupero per i file registrati; sistemi esterni e lavoro non registrato richiedono comunque un piano di recupero proprio.
**Regola 1. Fai un commit ogni 30 minuti.** Non aspettare che «l'attività sia terminata». Fai un commit di ogni passaggio intermedio funzionante. I messaggi di commit possono essere qualsiasi cosa; l'importante è che Claude (o tu) possa tornare a uno stato funzionante con un solo comando `git checkout`. ```bash # at the beginning of a task git status # inspect all staged and unstaged paths git diff # review the changes # Replace this example path with the actual file you reviewed. git add -- path/to/file.ts git diff --cached # verify exactly what will be committed git commit -m "wip: starting User schema migration" # after 30 minutes (or after the first working iteration) git status git diff git add -- path/to/file.ts # actual reviewed path, not a directory wildcard git diff --cached git commit -m "wip: User schema is ready, migration applied locally" # at the end of the task—a meaningful commit git reset --soft HEAD~2 # combine the three wip commits into one git commit -m "feat(auth): add lastLoginAt field to User table" ``` Se aggiungi un promemoria PostToolUse, mantieni la stessa revisione e l’aggiunta di percorsi espliciti. Non trasformare il timer in commit automatici incontrollati: modifiche estranee o file già in staging potrebbero entrarvi. **Regola 2. `.gitignore` minimo.** Queste righe sono richieste nella radice del progetto: ```gitignore # secrets .env .env.local .env.*.local # local Claude Code settings (not pushed to the team repository) .claude/personal/ .claude/sessions/ .claude/file-history/ # dependencies and build node_modules/ dist/ .next/ build/ ``` Tengo la cartella `.claude/personal/` per i miei esperimenti e appunti, che non devono entrare nel repository condiviso. Le cartelle `.claude/sessions/` e `.claude/file-history/` sono l'archiviazione locale di Claude Code: non appartengono al repository, occupano molto spazio e sono legate a una specifica macchina. **Regola 3. Fai gli esperimenti su un branch separato.** Se l'attività è ampia (rifattorizzare più di 10 file, migrare a un nuovo database, riscrivere un modulo), non farla sul branch principale: ```bash git checkout -b experiment/auth-rewrite # work, commit every 30 minutes # if it works: git checkout main git merge experiment/auth-rewrite # if it doesn't: git checkout main git branch -D experiment/auth-rewrite # delete the branch # that's it, the main branch is intact ``` Questa semplice abitudine trasforma «Claude ha distrutto il progetto» in «Claude ha distrutto un branch, l'ho eliminato e ricominciamo». **Regola 4. Prima delle operazioni rischiose, usa `git tag`.** Prima di una migrazione del database, di una rifattorizzazione ampia o di un aggiornamento delle dipendenze, crea un tag: ```bash git tag pre-prisma-migration-v2 # work # something went wrong: git reset --hard pre-prisma-migration-v2 # or just take a look: git checkout pre-prisma-migration-v2 ``` Un tag è un puntatore con nome a un commit, che non perderai neppure con la pulizia del reflog. ## Qual è il passo successivo: che posto ha l'annullamento nel context engineering?
Punti chiave L'annullamento non è una competenza a sé, ma fa parte della gestione del contesto della sessione di Claude Code. Quando sai quando premere `/rewind`, quando fare `git commit` e quando usare `git stash`, gestisci un intero flusso di lavoro, non un singolo comando. Questo rientra nel **Context Engineering**. Senza di esso, Claude agisce come un assistente ordinario; con esso, come uno strumento prevedibile.
Questi tre livelli di annullamento sono l'infrastruttura di una competenza: sapere come ripristinare uno stato quando si rompe qualcosa. Presa da sola, è una competenza limitata. Ma insieme ad altri strumenti di context engineering diventa qualcosa di più. Plan Mode non permette di scrivere codice immediatamente: prima viene il piano, poi la conferma e infine l'esecuzione. È un annullamento preventivo: non scrivi qualcosa che poi dovrai annullare, perché il piano è stato esaminato in anticipo. Leggi di più nella guida a [Plan Mode in Claude Code](https://ailoot.ai/blog/it/claude-code-plan-mode/). [CLAUDE.md](https://ailoot.ai/blog/it/claude-md-template/) stabilisce regole che Claude rispetta per impostazione predefinita, tra cui il Protocollo di sicurezza Git descritto sopra. È una protezione preventiva dai comandi distruttivi. Il [Second Brain](https://ailoot.ai/blog/it/claude-code-second-brain/) dà a Claude memoria del progetto tra una sessione e l'altra: conosce il codice che hai, la logica di business e gli accordi presi in precedenza. Più memoria c'è, meno è probabile che faccia la cosa sbagliata. [Skills e subagenti](https://ailoot.ai/blog/it/claude-code-skills-library/) sono la tua metodologia espressa in codice. Se il flusso di lavoro Git corretto è integrato in una Skill, nessun subagente eseguirà `git reset --hard` senza conferma. E tutto questo insieme è **Context Engineering**. Gestisci il contesto prima del prompt, non durante. Leggi di più in [che cos'è il context engineering](https://ailoot.ai/blog/it/context-engineering/). L'annullamento è l'ultima linea di difesa. Plan Mode + CLAUDE.md + Second Brain + Skills sono le prime quattro. Quando sono configurate, annullare diventa raro e rapido. Quando non lo sono, diventa un rituale quotidiano.
### Fonti - [Anthropic Docs - Checkpointing](https://code.claude.com/docs/en/checkpointing) - [Anthropic Docs - What's new (Week 20, 11-15 May 2026)](https://code.claude.com/docs/en/whats-new) - [Anthropic Docs - Permission Modes](https://code.claude.com/docs/en/permission-modes) - [Git Reference - reflog](https://git-scm.com/docs/git-reflog)
Annullare comincia dove finisce la pianificazione. [Apri Ailoot](https://ailoot.ai/). ## Domande frequenti ### Un checkpoint WIP deve usare git add .? No. Esegui `git status` e `git diff`, aggiungi soltanto i file nominati che hai revisionato e verifica `git diff --cached` prima del commit. Un controllo periodico non autorizza a includere modifiche estranee o già nell’area di staging. ### /rewind annulla una migrazione del database o un’azione API remota? No. La guida limita i checkpoint alle modifiche supportate dei file nella sessione. Database, Git remoto e API richiedono recuperi separati; usa Git o un backup per i file fuori dalla copertura dei checkpoint. ## Ailoot · L’azienda e il suo portafoglio di progetti Ailoot si basa su un’esperienza operativa consolidata, un’ampia base di clienti, un servizio stabile e un controllo costante dei KPI. L’azienda e il suo portafoglio di progetti: milioni di clienti; vendite nell’ordine dei miliardi ogni mese. Ailoot mette questa esperienza operativa al servizio dell’accesso API alle funzioni AI nei prodotti dei clienti, negli agenti, nelle applicazioni e nelle automazioni.