Séquence 04 · Revenir à une version
Vendredi, ça marchait
La promesse de l’album photo, c’est de pouvoir y retourner. Il y a trois gestes différents — et les distinguer, c’est toute la sérénité de Git.
Trois gestes, trois intentions
Avant les commandes, clarifions ce que vous voulez faire. Ce sont trois situations très différentes :
Regarder le passé. « Je veux juste voir l’état de vendredi, vérifier un chiffre, relancer le programme tel qu’il était. » Rien n’est modifié — on visite.
Restaurer un fichier. « Mes modifications du matin sont ratées, je veux récupérer ce fichier tel qu’il était à la dernière photo — ou à une photo plus ancienne. » Un fichier revient en arrière, le reste ne bouge pas.
Annuler un commit. « Cette modification enregistrée hier était une erreur, je veux l’annuler proprement, en gardant la trace de tout. » L’histoire continue vers l’avant, avec un commit d’annulation.
Geste 1 — Regarder le passé
Le programme tournait parfaitement au commit 51bd882. Allons voir cet état, sans rien toucher :
git log --oneline
git switch --detach 51bd8828f31c2a Modifie le calcul de l'indicateur
51bd882 Version stable avant modification
a904ef1 Ajoute le graphique par sexe
Note : basculement sur '51bd882'.
Vous êtes dans un état « HEAD détachée » : vous pouvez regarder,
compiler, tester... vos fichiers sont exactement dans l'état
de ce commit.Ouvrez analyse.R : c’est la version de vendredi. Relancez vos calculs : ce sont les chiffres de vendredi. Vous êtes en visite dans le passé — Git a simplement remis vos fichiers dans l’état de cette photo.
Quand la visite est finie, on revient au présent :
git switch mainBasculement sur la branche 'main'main est le nom de la ligne principale de votre projet — le présent. Quel que soit l’endroit de l’album où vous êtes allé vous promener, git switch main vous ramène toujours à l’état actuel. C’est votre bouton « retour à la maison ».
Pendant une visite du passé (« HEAD détachée »), ne créez pas de nouveaux commits : ils seraient rattachés à rien et difficiles à retrouver. La visite, c’est pour regarder. On modifie et on commite uniquement une fois revenu sur main.
Geste 2 — Restaurer un fichier
Cas A : annuler mes modifications du matin (non commitées)
Depuis 9 h, vous retouchez analyse.R… et c’est de pire en pire. Vous voulez repartir de la dernière photo :
git restore analyse.RPas de message : Git a silencieusement remis analyse.R dans l’état du dernier commit. Vos retouches du matin sont effacées — c’était le but.
git restore supprime définitivement les modifications non commitées du fichier : elles n’étaient dans aucune photo, il n’y a rien à récupérer. Prenez le réflexe : git diff analyse.R d’abord, pour relire ce que vous êtes sur le point de jeter.
Cas B : récupérer la version d’un ancien commit
Le graphique était meilleur dans la version 51bd882 ? Récupérez le fichier tel qu’il était sur cette photo-là, sans toucher au reste du projet :
git restore --source=51bd882 analyse.R
git statusSur la branche main
Modifications qui ne seront pas validées :
modifié : analyse.RRegardez bien le git status : le fichier restauré apparaît comme une modification ordinaire. Rien n’est encore enregistré — vous pouvez comparer avec git diff, ajuster, puis commiter cette restauration comme n’importe quel changement. Vous gardez la main à chaque étape.
Geste 3 — Annuler proprement un commit
Le commit 8f31c2a (« Modifie le calcul de l’indicateur ») s’avère être une erreur : les chiffres validés étaient les bons. Ce commit a déjà été partagé avec l’équipe — impossible de faire comme s’il n’avait jamais existé. La bonne solution : un commit qui défait.
git revert 8f31c2a[main 9c8d7e6] Revert "Modifie le calcul de l'indicateur"
1 fichier modifié, 3 insertions(+), 3 suppressions(-)L’historique raconte alors toute la vérité :
- 9c8d7e6 Revert "Modifie le calcul de l'indicateur"
- 8f31c2a Modifie le calcul de l'indicateur
- 51bd882 Version stable avant modification
L’erreur reste dans l’album, son annulation aussi. Dans six mois, on comprendra exactement ce qui s’est passé — et si l’idée redevient pertinente, tout est encore là.
Pour aller plus loin — et git reset --hard, qu’on voit partout sur Internet ?
git reset --hard réécrit l’histoire : il fait disparaître des commits comme s’ils n’avaient jamais existé. Sur un travail partagé, c’est la recette des catastrophes — vos collègues ont, eux, encore l’ancienne histoire. Tant que vous débutez, considérez que cette commande n’existe pas : git restore pour les fichiers, git revert pour les commits couvrent tous vos besoins réels, sans jamais rien perdre. Le jour où un reset sera vraiment justifié, vous saurez exactement pourquoi — et ce jour n’est pas aujourd’hui.
Le bon geste, du premier coup
| Votre situation | Le geste | La commande |
|---|---|---|
| « Je veux voir l’état de vendredi » | Visiter | git switch --detach <commit> puis git switch main |
| « Mes retouches non commitées sont ratées » | Restaurer | git restore fichier |
| « Je veux ce fichier tel qu’il était avant » | Restaurer depuis une photo | git restore --source=<commit> fichier |
| « Ce commit partagé était une erreur » | Annuler en avançant | git revert <commit> |
Vous avez passé la matinée à modifier traitement.py sans commiter, et tout est à jeter. Quel geste ?
revert annule un commit ; or ici rien n'a été commité. switch --detach sert à visiter. Pour jeter des modifications non enregistrées d'un fichier : restore.
Dans votre dossier d’exercice : modifiez analyse.R n’importe comment (cassez-le, vraiment), vérifiez les dégâts avec git diff, puis récupérez la version saine avec git restore analyse.R. Sentez ce que cela change : vous ne pouvez plus perdre un travail commité. Expérimenter, casser, tester devient sans danger.