# Comment annuler des modifications dans Claude Code : /rewind et git > Modes de rewind, limites des checkpoints, git checkout, stash, reflog et protection contre les commandes destructrices. Cinq façons de restaurer un état. Source: https://ailoot.ai/blog/fr/claude-code-undo-changes/ Canonical: https://ailoot.ai/blog/fr/claude-code-undo-changes/ Language: fr Publisher: Ailoot (https://ailoot.ai/) Translation: guide-138 Revision: sha256-2003b5abec3c691085fae76a7d302659a2850f31e32670ae0c349af7b6527561 [Des informations pratiques sur l’utilisation d’Ailoot sont disponibles dans la documentation](https://ailoot.ai/docs/). ## Qu’est-ce que l’annulation dans Claude Code, et pourquoi trois niveaux ne suffisent-ils pas ?
Points clés L’annulation dans Claude Code comporte trois niveaux : la commande intégrée `/rewind` (récupération instantanée au sein d’une session), `git checkout` (restauration au dernier commit) et `git reflog` (filet de sécurité en cas de catastrophe si quelqu’un a exécuté `git reset --hard`). Chaque niveau couvre sa propre catégorie d’erreurs, et rien au-delà de ses limites. Ne connaître que `/rewind`, c’est se retrouver complètement démuni à la première grosse erreur.
J’ai activé `/rewind` pendant ma première semaine d’utilisation de Claude Code, après qu’il a cassé la logique d’authentification de mon projet en deux prompts. J’ai fait un rewind, soufflé un bon coup et repris le travail. Un mois plus tard, une autre situation s’est présentée : j’écrivais une migration de schéma, Claude m’a aidé, j’ai fait un commit, changé de branche, puis je me suis rendu compte que j’avais oublié une étape nécessaire. `/rewind` n’a pas aidé : la session était déjà différente. `git checkout` vers le commit précédent, oui. Un mois après, j’ai accidentellement dit à l’agent : « remets tout à l’état du dernier push », et il a exécuté `git reset --hard`, détruisant trois heures de travail. `git reflog` m’a sauvé : les hashes des commits détruits étaient encore là. Ces trois histoires illustrent trois niveaux de protection qui fonctionnent différemment, détectent des erreurs distinctes et sont tous nécessaires. Ce guide explique chaque niveau, avec ses commandes, ses limites et des exemples. Il montre aussi comment configurer un projet à l’avance pour que Claude ne le mette pas à terre dès la première fois. **3 niveaux d’annulation — quoi et quand :** | Niveau | Commande | Couvre | NE couvre PAS | |----|----|----|----| | 1\. Au sein d’une session | `/rewind` ou `Esc Esc` | Les fichiers modifiés par Claude avec ses propres outils ; l’historique de la conversation | Les commandes bash, les éditeurs externes, les migrations de base de données | | 2\. Avant un commit | `git checkout .` ou `git stash` | Toutes les modifications non commitées des fichiers | Les commits déjà créés | | 3\. Catastrophe | `git reflog` + `git reset --hard ` | Les commits détruits par `reset --hard` ou un force-push | Les commandes bash destructrices (rm, migrations de base de données) | Nous allons maintenant passer en revue chaque niveau : ce qu’il faut faire précisément, les pièges à éviter et comment configurer les choses pour n’avoir rien à annuler parce que rien n’a cassé. ## Comment lancer /rewind : avec la commande ou Esc-Esc ?
Points clés Il existe deux façons d’ouvrir le menu Rewind dans Claude Code. La première consiste à saisir `/rewind` dans le champ de saisie. La seconde consiste à appuyer deux fois sur `Esc` lorsque le champ est vide. S’il contient du texte, le premier double appui sur Esc l’efface et enregistre son contenu dans l’historique de saisie ; un autre double appui ouvre le menu. La commande `/rewind` est un alias de `/checkpoint`.
Après chaque réponse, Claude prend automatiquement un instantané de tous les fichiers qu’il a modifiés pendant cette session. Les instantanés sont enregistrés dans `~/.claude/file-history/{sessionId}/` et conservés jusqu’à 30 jours. Ils sont incrémentiels : seules les différences entre les états sont enregistrées, pas le fichier entier. Par défaut, jusqu’à 100 instantanés sont stockés par session. Cela signifie que, dans la plupart des projets réels, tu disposes à tout moment d’un historique complet de toutes les modifications apportées par Claude au cours de la journée de travail. Pour ouvrir le menu Rewind, appuie deux fois sur `Esc` lorsque le champ de saisie est vide : ``` [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) ... ``` Si le champ de saisie contient du texte, le premier double appui sur `Esc` l’efface et l’enregistre dans l’historique, accessible avec la touche `Up`. C’est utile si tu as déjà commencé à taper et que tu te rends compte qu’il faut faire un rewind. Voici une citation de la documentation officielle d’Anthropic :

« S’il y a du texte dans le champ de prompt, double Esc l’efface d’abord au lieu d’ouvrir le menu. Le texte effacé est enregistré dans l’historique de saisie, afin que tu puisses le restaurer avec la flèche vers le haut après le menu de rewind. »

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
La commande `/rewind` fait la même chose : elle ouvre le menu. Il existe un alias, `/checkpoint`, qui mène au même endroit. La méthode la plus pratique dépend des habitudes de chacun. J’utilise `Esc Esc` : c’est plus rapide et je n’ai pas à retirer les mains du clavier. ## 6 modes dans le menu Rewind : lequel choisir, et quand ?
Points clés Après avoir sélectionné un point de rewind dans le menu Rewind, un second menu apparaît avec six modes. Trois restaurent un état (`Restore code and conversation`, `Restore conversation`, `Restore code`), deux compressent l’historique (`Summarize from here`, `Summarize up to here`) et un annule l’action (`Never mind`). Le scénario le plus courant — « revenir à la fois sur le code et la conversation » — correspond à la première option.
Choisis un point dans la liste pour accéder au menu des actions. Six options, chacune ayant un effet différent. **Tableau complet des modes :** | Mode | Fonctionnement | Quand le choisir | |----|----|----| | `Restore code and conversation` | Restaure les fichiers et l’historique de la conversation au point sélectionné | Le scénario le plus courant : Claude est parti dans la mauvaise direction et je veux recommencer avec la bonne formulation | | `Restore conversation` | Restaure uniquement l’historique de la conversation ; les fichiers restent tels qu’ils sont | Le code est bon, mais la conversation a dévié ; je vais reformuler à partir de ce point tout en conservant les modifications actuelles | | `Restore code` | Restaure les fichiers ; la conversation reste telle quelle | Certaines modifications de Claude étaient inutiles, mais j’ai encore besoin du contexte de la conversation (par exemple, nous nous sommes mis d’accord sur les prochaines étapes) | | `Summarize from here` | Résume tout ce qui se trouve APRÈS le point sélectionné. Ne touche pas aux fichiers | Une longue session de débogage a épuisé le contexte ; je dois libérer de la place tout en conservant intégralement les instructions initiales | | `Summarize up to here` | Résume tout ce qui se trouve AVANT le point sélectionné. Ne touche pas aux fichiers | Un long briefing initial a été suivi d’une tâche précise : nous condensons le briefing en un seul message et laissons le travail récent tel quel | | `Never mind` | Ferme le menu sans rien modifier | J’ai changé d’avis | La fonction `Summarize up to here` est apparue dans Claude Code v2.1.139-v2.1.142, publié du 11 au 15 mai 2026, pendant la semaine 20 :

« Tu peux compresser le contexte initial depuis le menu Rewind en utilisant “Summarize up to here”. »

— Anthropic What's new, https://code.claude.com/docs/en/whats-new
La différence entre `Restore` et `Summarize` est fondamentale. Restore ramène à un état antérieur et annule tout ce qui s’est passé après le point sélectionné. Summarize ne défait rien : il compresse uniquement le contenu. Les messages d’origine restent dans la transcription de la session pour référence, mais seul le résumé subsiste dans le contexte actif. Utilise Restore quand tu veux que ce soit « comme si rien de tout cela ne s’était passé ». Utilise Summarize quand tu veux « le garder, mais sans occuper d’espace dans le contexte ». Après `Restore conversation` ou `Summarize from here`, le texte d’origine du prompt sélectionné réapparaît dans le champ de saisie : tu peux le modifier et le renvoyer. Après `Summarize up to here`, le champ de saisie est vide et tu restes à la fin de la conversation. ## Quelles modifications /rewind NE défait-il PAS ?
Points clés `/rewind` suit uniquement les modifications faites par Claude avec ses propres outils d’édition de fichiers. Il ne peut ni voir ni restaurer quoi que ce soit d’autre. Il existe trois catégories de modifications invisibles : les commandes bash (rm, mv, cp), les modifications externes (tes modifications manuelles dans un IDE, les changements provenant d’autres sessions) et les opérations hors des fichiers (migrations de base de données, git push, appels à des API distantes).
C’est la principale limite à laquelle les gens se heurtent : `/rewind` affiche une coche verte et indique « rewind successful », mais le projet est toujours cassé parce que Claude a touché autre chose que des fichiers. Examinons les trois cas. **1. Les commandes bash ne sont pas suivies.** Si Claude exécute `rm file.txt` ou `mv old.txt new.txt` au cours d’un tour, ces modifications ne sont pas incluses dans le checkpoint. La documentation d’Anthropic le précise explicitement :

« Les checkpoints ne suivent pas les fichiers modifiés par des commandes bash. Par exemple, si Claude Code exécute rm file.txt, mv old.txt new.txt ou cp source.txt dest.txt, ces modifications de fichiers ne peuvent pas être annulées avec rewind. »

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Cela signifie que si Claude supprime, déplace ou copie un fichier de son propre chef avec l’outil bash, `/rewind` ne restaurera pas tout. `git checkout` ou une restauration depuis une sauvegarde peut aider, mais cela demande plus que d’appuyer sur deux touches. **2. Les modifications externes ne sont pas prises en compte.** Si tu ouvres manuellement un fichier dans VS Code et le modifies, ou si une seconde session Claude modifie les mêmes fichiers en parallèle, la première session ne peut pas voir ces changements. Un instantané du checkpoint est pris lorsque Claude termine un tour dans la session en cours. Ce qui se passe entre les tours ne relève pas de sa responsabilité. **3. Les opérations hors des fichiers ne sont pas couvertes du tout.** Une migration Prisma appliquée avec `npx prisma migrate dev` a modifié le schéma de la base de données : `/rewind` ne l’annulera pas, car la base se trouve en dehors du système de fichiers du projet. Un force-push vers `origin/main`, c’est pareil : le commit est parti sur le serveur distant et le checkpoint ne le fera pas revenir. Un appel à une API distante qui a débité de l’argent ou supprimé un enregistrement ne peut être annulé qu’au moyen des mécanismes propres à cette API. **Règle :** si une tâche a des effets en dehors des fichiers du projet — migrations de base de données, git push, API distantes —, prépare une stratégie de restauration distincte pour chaque effet externe. `/rewind` ne couvre que l’historique des fichiers locaux dans la session en cours. ## /rewind et git : en quoi diffèrent-ils, et pourquoi faut-il les deux ?
Points clés `/rewind` est un retour arrière local au sein d’une seule session Claude Code. Il stocke des instantanés incrémentiels jusqu’à 30 jours, à raison de 100 au maximum par session. git est l’historique de projet à long terme, partagé avec l’équipe, avec des branches, des conflits de fusion et un dépôt distant. L’un ne remplace pas l’autre. La bonne pratique consiste à faire un `git commit` à chaque étape logique et à s’appuyer sur `/rewind` entre les commits.
La documentation d’Anthropic décrit directement cette complémentarité :

« Les checkpoints sont conçus pour une récupération rapide à l’échelle d’une session. Pour les commits, les branches et l’historique à long terme, continue à utiliser un système de gestion de versions (par exemple, Git). Les checkpoints complètent la gestion de versions habituelle, mais ne la remplacent pas. Considère les checkpoints comme une “annulation locale” et Git comme un “historique permanent”. »

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Les différences en un tableau : | Paramètre | /rewind | git | |----|----|----| | Granularité | Chaque tour de la conversation | Chaque commit | | Stockage | Jusqu’à 30 jours, 100 par session maximum, en local dans `~/.claude/file-history/` | De façon permanente, dans le `.git/` du dépôt et sur le serveur distant | | Ce qui est suivi | Les modifications de Claude avec ses propres outils | Toutes les modifications commitées | | Ce qui N’est PAS suivi | Bash, modifications externes, migrations, push | Les modifications non commitées | | Commande | Une commande au sein de Claude | Un système de gestion de versions externe | | Revient sur la conversation | Oui | Non | | Fonctionne entre les sessions | Uniquement au sein de la même session | Partout | La complémentarité est simple : dès que tu arrives à un état où « ça fonctionne et je ne veux pas le perdre », fais un `git commit`. Entre les commits, fie-toi à `/rewind` : c’est immédiat, ne demande aucun message de commit et n’encombre pas l’historique git avec des états intermédiaires. Quand le travail est terminé, fais un commit — de préférence pertinent et atomique. ## Pourquoi un seul /rewind ne couvre-t-il pas toute la tâche ? L’annulation est un cas de **Context Engineering**. En gérant le contexte de la session (quand faire un commit, quand appuyer sur `/rewind`, quelles règles mettre dans `CLAUDE.md`), tu obtiens un Claude prévisible qui ne détruit pas le projet et ne perd pas de travail. ## Pourquoi `git reset --hard` est-il dangereux quand tu demandes à Claude de « revenir en arrière » ?
Points clés En langage naturel, « revenir en arrière » signifie « consulter l’historique », pas « le détruire » ; Claude devrait proposer `git checkout` par défaut, et non `reset --hard` ; la protection se configure dans CLAUDE.md.
Une demande d’« enregistrer l’état actuel et de revenir au dernier push » peut aboutir à ces commandes : ```bash git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix" # saved uncommitted changes git reset --hard 35eb731 # destroyed commits d63695e..882e618 ``` La première commande était correcte : elle a enregistré les modifications non commitées dans le stash. La seconde était destructrice : elle a réécrit la branche vers le commit `35eb731`, et tous les commits entre celui-ci et `882e618` sont devenus orphelins. Par défaut, les commits orphelins restent dans `.git/objects/` jusqu’à l’exécution de `git gc`, qui se lance généralement automatiquement dans les deux semaines. Mais si tu ne savais pas quoi faire à ce moment-là, le temps jouait déjà contre toi. La logique est simple : en langage naturel, « revenir en arrière », « retourner en arrière », « restaurer », « revenir sur » et « annuler » signifient « regarder l’historique » ou « revenir à un endroit sûr ». Cela ne signifie pas « détruire l’historique ». La commande `git reset --hard` le détruit : elle réécrit la branche et retire des commits de l’ensemble de ceux qui sont accessibles par HEAD. Une alternative sûre est `git checkout `, qui crée un HEAD détaché et permet de consulter l’ancien état sans toucher aux branches. La principale leçon pratique consiste à faire un `git commit` de l’état actuel avant toute tâche importante, en particulier avant de refactoriser plusieurs fichiers. Un commit transforme n’importe quelle erreur de Claude en une seule commande `git checkout .`, sans perte de travail. ## Comment git reflog te sauve-t-il après un reset destructeur ?
Points clés `git reflog` affiche l’historique local de tous les déplacements de HEAD dans le dépôt, y compris les commits supprimés par `git reset --hard` ou un force-push. Chaque déplacement est conservé pendant 90 jours par défaut. Si Claude (ou toi, ou quelqu’un d’autre) a détruit des commits avec une commande destructrice, `git reflog` affichera leurs hashes, et tu pourras restaurer la branche avec `git reset --hard `.
Après un reset destructif, exécute `git reflog` immédiatement : ```bash git reflog ``` La sortie ressemble à ceci : ``` 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}` à `HEAD@{3}` sont précisément ces commits « détruits ». Ils n’ont pas disparu du magasin d’objets local de git ; ils sont simplement devenus inaccessibles via la branche. Pour les restaurer : ```bash # Create a branch from the last “destroyed” commit git branch recovered-work 882e618 # Or switch directly git reset --hard 882e618 ``` Après cela, la branche contient à nouveau tout l’historique jusqu’à la catastrophe. **Limites de Reflog :** 1. **Local uniquement.** Le reflog est stocké dans `.git/logs/HEAD` ; il ne se trouve pas dans le dépôt distant. Si tu fais un force-push puis supprimes ta copie locale du dépôt, le reflog disparaît avec le dossier. 2. **90 jours par défaut.** Les entrées plus anciennes peuvent être supprimées par git gc. Tu peux configurer cette durée avec `git config gc.reflogExpire 200.days.ago`. 3. **Ne couvre pas ce qui n’a jamais été dans HEAD.** Si un commit se trouvait uniquement dans le stash et que celui-ci a été détruit, le reflog n’affichera que son dernier état, pas son historique interne. **Règle pour l’équipe :** n’exécute jamais `git gc --aggressive` juste après une catastrophe. Examine d’abord le reflog et récupère le travail ; tout le reste vient après. Et ne supprime jamais le clone local du dépôt avant d’être sûr que tout ce dont tu as besoin a été poussé. ## Comment protéger un projet des commandes git destructrices avec CLAUDE.md ?
Points clés Dans le `CLAUDE.md` de ton projet, ajoute un bloc d’instructions définissant les commandes git que Claude peut exécuter seul, celles qui nécessitent une confirmation explicite et celles qui sont interdites sans une formulation exacte de l’utilisateur. Claude traite CLAUDE.md comme le prompt système du projet et suit ces règles par défaut. Ainsi, un prompt « dangereux » se transforme en deux commandes sûres.
La vulnérabilité est que Claude ne dispose par défaut d’aucun contexte de protection. Il interprète « revenir en arrière » comme `git reset --hard`, car c’est techniquement une méthode valide. Ajoute la protection dans `CLAUDE.md`, le fichier contenant le prompt système du projet. **Règle minimale** (à insérer dans ton `CLAUDE.md`) : ```markdown ## Git Safety Protocol - NE JAMAIS exécuter de commandes git destructrices (push --force, reset --hard, checkout ., restore ., clean -f, branch -D), sauf si je demande explicitement ces actions. Prendre des mesures destructrices sans autorisation n’est pas utile et peut entraîner une perte de travail. - Quand je dis « roll back », « go back », « restore », « revert » ou « undo », interprète cela comme des commandes d’EXAMEN : utilise `git log`, `git diff`, `git checkout ` (crée un HEAD détaché) ou `git stash` (préserve les modifications). - TOUJOURS demander confirmation avant TOUTE commande qui : - déplace la position de HEAD vers un autre commit sur une branche - modifie l’historique des commits - pourrait faire perdre du travail non commité - inclut les options --hard, --force, --aggressive - Avant toute commande destructrice, présenter une comparaison numérotée : - SÛRE : utiliser `git checkout ` pour consulter temporairement l’état - DESTRUCTRICE : utiliser `git reset --hard` pour détruire définitivement l’état - Attendre mon choix explicite avant l’exécution. ``` **Règle étendue** pour l’équipe (à ajouter au `CLAUDE.md` à la racine du dépôt) : ```markdown ## Git Workflow Rules - Fais un commit à chaque étape fonctionnelle. Avant un commit WIP, lance `git status` et `git diff`, indexe seulement les fichiers nommés explicitement revus avec `git add -- path/to/file`, puis inspecte le diff indexé. Le rappel horaire invite à la revue, sans autoriser l’ajout de tout l’arbre. - Claude ne doit jamais utiliser `git add .` ou `git add -A` pour ses commits. Indiquer uniquement les fichiers par leur nom, après `git status` + `git diff`. - Avant `git push --force` vers main, arrêter et me demander. Sur les branches de fonctionnalité, utiliser le force-push avec prudence et uniquement si tu es sûr que je suis prêt à perdre la version précédente. - Lors de la résolution de conflits de fusion, ne jamais choisir immédiatement « ours » ou « theirs » : montre-moi d’abord les deux versions, puis je déciderai. - `.gitignore` doit contenir `.env*`, `.claude/personal/`, `node_modules/`, `dist/`. S’il manque des entrées, les ajouter. ``` Après l’ajout de ces blocs, la prochaine phrase « reviens au dernier push » susciterait cette réponse : > Je vois 3 fichiers non commités et 4 commits depuis le dernier push. Deux options : > > 1. SÛRE : créer une branche `view-last-push` avec `git checkout ` — je préserverai tout le travail, mais afficherai temporairement l’état du push. > 2. DESTRUCTRICE : `git reset --hard ` — je détruirai définitivement 4 commits et les modifications non commitées. Elles ne pourront être restaurées qu’avec `git reflog` pendant 90 jours. Que choisis-tu ? Cela prend une demi-minute de conversation, au lieu de quatre heures de travail perdues. ## Quelles sont les 5 façons d’annuler dans Claude Code, et comment choisir la bonne ?
Points clés En cas de problème, il existe cinq niveaux d’escalade : `/rewind` (au sein d’une session), `git checkout .` (modifications non commitées), `git checkout ` (revenir à un ancien commit sans perdre l’historique), `git reset --hard ` (reculer la branche en perdant les commits qui la précèdent), `git reflog` + récupération (catastrophe, tout a disparu). Chaque niveau est plus lourd et plus dangereux que le précédent.
Le scénario « Claude a tout cassé, je dois restaurer rapidement » suit cette échelle de bas en haut. Commence toujours au niveau 1. **Niveau 1. `/rewind` — annulation instantanée au sein d’une session.** Appuie sur `Esc Esc` ou saisis `/rewind`. Choisis le point précédant le problème. Choisis un mode (généralement `Restore code and conversation`). Une seconde plus tard, tu es revenu dans le passé et tu peux recommencer. Couvre 80 % des cas où « Claude a fait fausse route ». **Niveau 2. `git checkout .` — annuler toutes les modifications non commitées.** ```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 lorsque `/rewind` n’a pas fonctionné (par exemple, si Claude a touché aux fichiers par bash) ou lorsque tu dois annuler des modifications en dehors de l’historique de la session. Toutes les modifications non commitées disparaîtront définitivement. Si tu risques de le regretter, exécute d’abord `git stash` (voir le niveau 2.5). **Niveau 2.5. `git stash` — mettre ses modifications de côté.** ```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 bon compromis entre « perdre pour toujours » et « laisser tel quel ». Le stash reste local jusqu’à ce qu’il soit explicitement supprimé. **Niveau 3. `git checkout ` — revenir à un ancien commit sans perdre l’historique.** ```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 ``` C’est un « retour temporaire » sans risque. Le HEAD détaché ne modifie pas la branche ; ton travail actuel dans `main` (ou la branche sur laquelle tu te trouvais) reste intact. Si tu veux travailler à partir de cet état, crée une branche. **Niveau 4. `git reset --hard ` — ramener la branche à un point donné.** ⚠️ Destructeur. Les commits situés après le hash indiqué deviennent orphelins. ```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 ``` À utiliser uniquement si tu es sûr de ne pas avoir besoin des commits situés après. Et vérifie toujours `git reflog` AVANT le reset pour savoir où revenir si tu changes d’avis. **Niveau 5. `git reflog` + récupération — scénario catastrophe.** Quelqu’un (Claude, toi, un collègue) a déjà exécuté `git reset --hard` ou un force-push et a effacé le travail. Que faire ? ```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 ``` Si le reflog a déjà été purgé (au bout de 90 jours par défaut), le dernier recours est `git fsck --lost-found`, qui affichera les commits pendants dans `.git/objects/`. C’est presque de l’archéologie, mais cela fonctionne parfois. **Règle pour choisir un niveau :** | Ce qui s’est passé | Niveau | |-----------------------------------------------|-----------------------------| | Claude a réécrit 3 fichiers de la mauvaise façon | 1\. `/rewind` | | J’ai essayé, ça ne m’a pas plu, la session n’aide pas | 2\. `git checkout .` | | J’ai cassé quelque chose manuellement, je ne veux pas le perdre et pourrais le restaurer | 2.5. `git stash` | | J’ai fait un commit et dois revenir d’un commit en arrière | 3\. `git checkout ` | | Je suis sûr de ne pas avoir besoin des commits situés avant | 4\. `git reset --hard` | | Je l’ai déjà effacé avec une commande destructrice | 5\. `git reflog` | ## Comment protéger un projet pour n’avoir rien à annuler ?
Points clés La meilleure annulation est celle dont tu n’as pas besoin. Trois règles de protection : revoir les progrès toutes les 30 minutes et commiter une étape fonctionnelle en indexant explicitement les seuls chemins revus ; mettre les lignes `.claude/personal/` et `.env*` requises dans `.gitignore` ; réaliser les expériences importantes dans une branche distincte avec `git checkout -b experiment-`. Cela réduit la fenêtre de récupération des fichiers commités ; systèmes externes et travail non commité exigent leur propre plan de restauration.
**Règle 1. Faire un commit toutes les 30 minutes.** N’attends pas que « la tâche soit terminée ». Commits chaque étape intermédiaire qui fonctionne. Les messages de commit peuvent être quelconques ; l’essentiel est que Claude (ou toi) puisse revenir à un état fonctionnel avec une seule commande `git checkout`. ```bash # at the beginning of a task git status # inspecter les chemins indexés et non indexés git diff # revoir les changements # Remplacer ce chemin illustratif par le fichier réellement revu. git add -- path/to/file.ts git diff --cached # vérifier le contenu exact du futur commit 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 # chemin réellement revu, pas un dossier entier 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" ``` Si tu ajoutes un rappel PostToolUse, garde la revue et l’indexation explicite des chemins. Ne transforme pas le minuteur en commit automatique non vérifié : des modifications sans rapport ou déjà indexées pourraient y entrer. **Règle 2. `.gitignore` minimal.** Ces lignes sont requises à la racine du projet : ```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/ ``` Je garde le dossier `.claude/personal/` pour mes propres expériences et notes, qui ne doivent pas être incluses dans le dépôt partagé. Les dossiers `.claude/sessions/` et `.claude/file-history/` sont le stockage local de Claude Code ; ils n’ont pas leur place dans le dépôt, prennent beaucoup de place et sont liés à une machine donnée. **Règle 3. Faire ses expériences sur une branche distincte.** Si la tâche est importante (refactorisation de 10+ fichiers, migration vers une nouvelle base de données, réécriture d’un module), ne la réalise pas sur la branche 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 ``` Cette simple habitude transforme « Claude a saccagé le projet » en « Claude a saccagé une branche, je l’ai supprimée et nous recommençons ». **Règle 4. Avant les opérations risquées, utiliser `git tag`.** Avant une migration de base de données, une refactorisation importante ou une mise à jour de dépendance, crée 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 est un pointeur nommé vers un commit que tu ne perdras pas, même après le nettoyage du reflog. ## Et ensuite : quelle place l’annulation occupe-t-elle dans le Context Engineering ?
Points clés L’annulation n’est pas une compétence à part, mais fait partie de la gestion du contexte de session de Claude Code. Quand tu sais quand appuyer sur `/rewind`, quand faire un `git commit` et quand utiliser `git stash`, tu gères un processus de travail complet, pas une seule commande. Cela relève du **Context Engineering**. Sans lui, Claude se comporte comme un assistant ordinaire ; avec lui, comme un outil prévisible.
Ces trois niveaux d’annulation forment l’infrastructure d’une compétence : savoir restaurer un état lorsqu’il casse. Cette compétence est en soi assez limitée. Mais combinée à d’autres outils de Context Engineering, elle devient quelque chose de plus. Le Plan Mode ne te laisse pas écrire du code tout de suite : d’abord vient le plan, puis la confirmation, puis l’exécution. C’est une annulation préventive : tu n’écris pas ce que tu devras annuler ensuite, car le plan a été examiné à l’avance. Pour en savoir plus, consulte le guide sur le [Plan Mode dans Claude Code](https://ailoot.ai/blog/fr/claude-code-plan-mode/). [CLAUDE.md](https://ailoot.ai/blog/fr/claude-md-template/) définit des règles que Claude respecte par défaut, notamment le Git Safety Protocol présenté plus haut. C’est une protection préventive contre les commandes destructrices. Le [Second Brain](https://ailoot.ai/blog/fr/claude-code-second-brain/) fournit à Claude une mémoire du projet entre les sessions : il sait quel code tu as, quelle est la logique métier et quels accords ont été pris auparavant. Plus il a de mémoire, moins il risque de faire fausse route. Les [Skills et les subagents](https://ailoot.ai/blog/fr/claude-code-skills-library/) sont ta méthodologie sous forme de code. Si le bon flux de travail git est intégré dans un Skill, aucun subagent n’exécutera `git reset --hard` sans confirmation. Tout cela forme le **Context Engineering**. Gère le contexte avant le prompt, pas pendant. Pour en savoir plus, lis [Qu’est-ce que le Context Engineering](https://ailoot.ai/blog/fr/context-engineering/). L’annulation est la dernière ligne de défense. Plan Mode + CLAUDE.md + Second Brain + Skills sont les quatre premières. Quand ils sont en place, l’annulation devient rare et rapide. Quand ils ne le sont pas, elle devient un rituel quotidien.
### Sources - [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)
L’annulation commence là où la planification s’arrête. [Accéder à Ailoot](https://ailoot.ai/). ## Questions fréquentes : Comment annuler des modifications dans Claude Code : /rewind et git ### Un checkpoint WIP doit-il utiliser git add . ? Non. Lance git status et git diff, indexe seulement les fichiers nommés que tu as revus, puis inspecte git diff --cached avant le commit. Un rappel périodique n’autorise pas l’ajout de changements sans rapport ou déjà indexés. ### /rewind annule-t-il une migration de base ou une action API distante ? Non. Les checkpoints du guide couvrent certaines modifications de fichiers de la session. Base, Git distant et API exigent des récupérations distinctes ; utilise Git ou une sauvegarde pour les fichiers hors de cette couverture. ## Ailoot · L’entreprise et son portefeuille de projets Ailoot s’appuie sur une expérience opérationnelle éprouvée, une large clientèle, un service stable et un suivi continu des KPI. L’entreprise et son portefeuille de projets : des millions de clients ; des ventes qui se chiffrent en milliards chaque mois. Ailoot met cette expérience opérationnelle au service de l’accès API aux fonctions d’IA dans les produits des clients, leurs agents, applications et automatisations.