Annuler sans paniquer
Le gain du jour : savoir faire marche arrière aux trois endroits où l’on se trompe — une modification ratée, un
git addde trop, un commit imparfait. C’est ce qui transforme Git d’un truc stressant en filet de sécurité.
Échauffement — de mémoire, sans tricher
0. Que compare git diff --staged ?
Trois erreurs, trois marches arrière
Chaque zone a sa gomme. La logique est toujours la même : ramener le fichier à l’état de la
zone d’à côté
(Pro Git, « Annuler des actions »).
Bonne nouvelle : git status te souffle la commande exacte à chaque fois — lis ses messages !
| « Oups… » | Commande | Effet |
|---|---|---|
J’ai modifié un fichier et je regrette (pas encore de add) | git restore <fichier> | Ramène le fichier du working directory à sa version en dernier commit |
J’ai fait git add trop vite | git restore --staged <fichier> | Sort le fichier de la staging area — tes modifications restent intactes dans le wd |
| Mon dernier commit a un message raté ou il manque un fichier | git commit --amend | Remplace le dernier commit du repository par une version corrigée (staging actuel + nouveau message) |
git restore <fichier> détruit définitivement tes modifications non
commitées — Git ne peut pas restaurer ce qu’il n’a jamais photographié. Avant de la lancer,
fais toujours git diff et relis ce que tu t’apprêtes à jeter.
En revanche, restore --staged ne détruit rien, et --amend garde tout.
--amend réécrit l’historique. C’est parfait tant que le commit est encore
uniquement sur ta machine — mais on ne réécrit jamais un commit déjà partagé
avec l’équipe (poussé sur GitHub). Retiens juste la règle, on verra pourquoi au jalon M4.
Entraîne-toi ici — terminal simulé
Avant de passer au vrai terminal, fais l’exercice dans ce simulateur : il accepte les vraies commandes du cours et valide ton résultat automatiquement. Erreur sans conséquence, bouton reset à volonté.
À toi de jouer
Direction ton dépôt d’entraînement — on va faire les trois erreurs exprès :
cd ~/Workspaces/pythons/git-entrainement
Erreur n°1 : la modif ratée. Sabote ton fichier, constate, puis annule :
echo "n'importe quoi qui casse tout" >> analyse.py git diff # relis ce que tu vas jeter — toujours ! git restore analyse.py git diff # plus rien : retour à la version du dernier commitErreur n°2 : le add trop rapide.
echo "score = 42" >> analyse.py git add analyse.py git status # lis bien : Git te suggère lui-même restore --staged git restore --staged analyse.py git status # le fichier est redevenu « not staged » — rien n'est perdu git diff # la ligne score = 42 est toujours là, dans le wdErreur n°3 : le message raté. Commite avec un mauvais message, puis répare :
git add analyse.py git commit -m "truc" git commit --amend -m "Ajoute le score de test" git log --oneline # « truc » a disparu : le commit a été remplacéBonus — le fichier oublié. Crée
notes.txt, commite autre chose, puis rattrape l’oubli :echo "penser à nettoyer les CSV" > notes.txt git add notes.txt git commit --amend --no-edit git log --oneline # toujours UN seul commit en plus : notes.txt a rejoint le dernier--no-edit= garder le message tel quel.Boucle d’entraînement (2 fois) : refais les erreurs 1 et 2 de mémoire, sans regarder la leçon. Si tu bloques,
git statuste souffle la réponse.
Vérifie ta compréhension
1. Tu as fait git add rapport.py par erreur. Comment le sortir de la prochaine photo sans perdre tes modifications ?
2. Pourquoi git restore <fichier> est-elle la commande dangereuse de cette leçon ?
3. Quand a-t-on le droit d'utiliser git commit --amend ?
Pour aller plus loin
📖 Source principale : Pro Git (fr) — « Annuler des actions ». Et garde en favori Oh Shit, Git!?! (fr) : les recettes de secours pour les jours où ça a vraiment dérapé.
🗂 Fiche mise à jour : Commandes Git — antisèche.