Ce que c'est et pourquoi ça compte
Ça arrive à tout le monde. Vous demandez une modification à Claude, il en fait dix, et une heure plus tard l'app ne démarre plus. Vous ne savez pas ce qu'il a touché et vous ne vous souvenez plus de comment c'était avant.
Git, c'est l'historique du projet. Chaque fois que vous sauvegardez avec un commit, vous prenez une photo de tous les fichiers à ce moment-là. Si quelque chose casse, vous revenez à une photo précédente. Mais seulement à une photo qui existe : si vous n'avez pas sauvegardé, il n'y a pas d'avant où revenir.
Les commandes Git, vous n'avez pas besoin de les apprendre. C'est Claude qui les écrit. Il vous suffit de trois phrases, telles quelles, aux trois bons moments : avant de commencer, quand quelque chose casse, avant un gros chantier.
Il faut seulement que le projet utilise Git. Si ce n'est pas encore le cas, demandez à Claude de le mettre en place : c'est une ligne.
1. Avant de commencer : sauvegarder
Avant de confier un travail à Claude, j'écris ceci :
Avant de toucher à quoi que ce soit, sauvegarde l'état actuel du projet avec un commit, comme ça on pourra revenir ici.
Claude fait un commit : il sauvegarde l'état actuel avec un message qui dit ce qu'il contient. Ce commit devient le point sûr. Quoi qu'il arrive ensuite, vous pouvez y revenir.
Je le fais aussi en cours de route, quand une partie fonctionne. Plus vous prenez de photos, plus le point où vous pouvez revenir est proche. Si le dernier commit date d'hier, revenir en arrière veut dire perdre tout ce que vous avez fait aujourd'hui.
2. Quand quelque chose casse : revenir en arrière
Quand l'app ne marche plus et que je ne comprends pas pourquoi, je ne demande pas à Claude de réparer la réparation de la réparation. J'écris :
Reviens à l'état d'il y a une heure. D'abord sauvegarde ce qui n'est pas encore sauvegardé et n'efface rien de l'historique : je veux pouvoir changer d'avis.
La phrase a trois morceaux, et chacun compte.
- « Reviens à l'état d'il y a une heure » : Claude regarde l'historique du projet et cherche le dernier commit avant ce moment. Vous pouvez aussi dire « à hier soir » ou « à avant que tu touches au login ».
- « D'abord sauvegarde ce qui n'est pas encore sauvegardé » : les modifications qui ne sont dans aucun commit sont les plus fragiles. Claude les met à l'abri avant de bouger, avec un commit ou avec git stash, qui les met de côté pour les reprendre plus tard.
- « N'efface rien de l'historique » : comme ça, Claude utilise git revert, qui n'efface pas les mauvais commits mais en ajoute un nouveau qui les annule. Tout l'historique reste là : si vous vous rendez compte qu'une partie du travail de la dernière heure était bonne, vous la récupérez.
L'inverse, c'est git reset --hard. Il ramène le projet en arrière et jette les modifications non sauvegardées dans les fichiers, sans passer par la corbeille. Parfois c'est utile, mais c'est la commande qui fait perdre du travail. C'est pour ça que ma phrase dit « je veux pouvoir changer d'avis ».
Quand il a fini, je demande une confirmation :
Dis-moi à quel commit tu es revenu, ce que tu as annulé, et lance les tests pour voir si ça marche maintenant.
3. Avant un gros chantier : une nouvelle branche
Refaire le login, changer la base de données, réécrire une page entière : ce sont des chantiers où les choses peuvent mal tourner en cours de route. Avant de commencer, j'écris :
Fais ce travail sur une nouvelle branche. Si ça marche et que les tests passent, fusionne-la avec la branche principale. Si ça ne marche pas, jette la branche et reviens à la bonne.
Une branche, c'est une version parallèle du projet. Claude travaille dessus, fait ses commits, et la version principale, en général main, reste comme elle était. Si le travail tient la route, il la fusionne : c'est le merge, les modifications de la branche entrent dans la version principale. Si ça ne marche pas, il jette la branche et vous êtes de nouveau sur le bon point.
« Les tests passent », c'est la partie qui compte. Sans vérification, « ça marche » veut seulement dire que ça a l'air fini pour Claude. Si le projet n'a pas de tests, demandez-lui au moins de lancer l'app et de vous dire comment il a vérifié.
Une branche modifie les fichiers dans le même dossier du projet, donc un chantier à la fois. Si vous voulez plusieurs sessions de Claude en parallèle, chacune sur sa branche, il vous faut des worktrees : un dossier séparé pour chaque branche. J'en parle dans le guide ALBERI (strikt.fit/alberi).
4. En plus : les checkpoints de Claude Code
En plus de Git, il y a un filet plus petit, déjà intégré à Claude Code. Chaque fois que vous envoyez un message, Claude Code note l'état des fichiers que Claude modifie avec ses propres outils. Ces points s'appellent des checkpoints, et il les crée tout seul.
Pour revenir à l'un de ces points, appuyez deux fois sur Esc avec le champ vide, ou tapez /rewind. S'il y a du texte dans le champ, le double Esc l'efface, c'est tout. La liste des messages que vous avez envoyés s'ouvre : choisissez le point et ce qu'il faut restaurer.
- Le code et la conversation : vous revenez à ce point avec les deux.
- Seulement la conversation : le chat revient à ce message, les fichiers restent comme ils sont maintenant.
- Seulement le code : les fichiers reviennent comme ils étaient, la conversation reste.
Les deux options sur le code n'apparaissent que si Claude a modifié des fichiers après ce point.
Ce qu'ils n'annulent pas
- Les commandes du terminal. Si Claude supprime ou déplace un fichier avec rm ou mv, le rewind ne le ramène pas.
- Les modifications faites en dehors de Claude Code : les fichiers que vous changez à la main dans l'éditeur, ou qu'une autre session change, ne sont en général pas suivis.
Combien de temps ils durent
Les checkpoints sont sauvegardés avec la conversation. Si vous fermez le terminal puis reprenez la même session, vous pouvez encore faire un rewind. Mais ils restent liés à cette session : une nouvelle session démarre sans eux. Et par défaut, Claude Code supprime les copies des fichiers environ 30 jours plus tard, avec les anciennes données de la session.
C'est pour ça qu'ils ne remplacent pas Git. C'est le bouton annuler de la session. Le vrai historique du projet, c'est Git qui le garde.
5. Une règle de sécurité
Le travail pas encore sauvegardé, c'est celui que vous pouvez vraiment perdre, et le moyen le plus courant, c'est un reset. C'est pour ça que chaque phrase dit à Claude de sauvegarder d'abord. Vous pouvez ajouter :
N'utilise jamais git reset --hard sans me le demander.
Si vous voulez qu'elle s'applique toujours, mettez-la dans le CLAUDE.md du projet, le fichier que Claude lit au début de chaque session. Ça reste une instruction : Claude la suit, mais ce n'est pas un blocage. Pour un vrai blocage, il y a la liste deny dans les paramètres, qui arrête la commande avant qu'elle parte : je l'explique dans le guide JEV (strikt.fit/jev).
Les erreurs les plus courantes
- Travailler des heures sans commit : Git ne revient qu'aux sauvegardes qui existent, donc faites sauvegarder avant chaque chantier et dès qu'une partie fonctionne.
- Faire réparer la réparation à l'infini : après deux essais ratés, revenez au bon point et repartez avec une demande plus claire.
- Compter sur le rewind pour tout : il n'annule ni les commandes du terminal ni les modifications faites en dehors de Claude Code, donc le vrai filet reste Git.
- Laisser passer un git reset --hard : il jette le travail non sauvegardé, donc demandez git revert et une sauvegarde avant.
- Faire un gros chantier sur la version principale : lancez-le sur une nouvelle branche, comme ça si ça tourne mal vous jetez la branche et ne perdez rien.
- Fusionner une branche sans vérifier : lancez les tests avant le merge, pas après.
Check-list
- Le projet utilise Git
- Commit avant chaque chantier
- Commit quand une partie fonctionne
- Pour revenir en arrière : git revert, pas de reset
- Les gros chantiers sur une nouvelle branche
- Tests avant de fusionner la branche
- Rewind seulement pour les modifications de Claude dans la session
Questions fréquentes
Quelle différence entre le rewind et revenir en arrière avec Git ?
Le rewind annule les modifications de fichiers faites par Claude dans cette session, message par message, et il peut aussi ramener la conversation en arrière. Git revient à un commit, pour tous les fichiers du projet, peu importe qui les a changés et comment, même il y a des semaines. Pour une erreur d'il y a cinq minutes j'utilise le rewind, pour tout le reste Git.
Et si je dis « il y a une heure » mais que je n'ai fait aucun commit ?
Git ne peut revenir qu'à un commit qui existe. Si le dernier date de ce matin, vous revenez à ce matin. Pour les modifications que Claude a faites dans cette session, vous pouvez utiliser le rewind : choisissez le message d'il y a une heure et restaurez le code.
Est-ce que je dois apprendre les commandes Git ?
Non. Les phrases sont en langage courant et c'est Claude qui écrit les commandes. Ça vaut la peine de reconnaître deux noms : git revert, qui annule sans effacer, et git reset --hard, qui peut jeter du travail. Si vous voyez le second dans une demande d'autorisation, arrêtez-vous et demandez pourquoi.