Annuler un commit déjà partagé

Un commit publié peut contenir une erreur, mais le supprimer de l’historique créerait des divergences chez les personnes qui l’ont déjà récupéré. Vous allez annuler ses effets en ajoutant une nouvelle version qui fait l’opération inverse. Le commit d’origine restera visible et l’historique continuera d’avancer.

Dans la leçon « Retirer un fichier de la préparation », vous avez laissé une note non préparée dans `README.md`. Elle n’empêche pas de préparer une annulation si le commit ciblé ne modifie pas ce fichier ; vous contrôlerez ce point avant d’agir. Le dépôt distant n’a pas encore été configuré dans le parcours : la notion de commit partagé est donc présentée ici dans le contexte où une version a déjà été communiquée à d’autres personnes.

Commencez par afficher les commits récents et repérez celui dont vous souhaitez annuler les effets. Ne choisissez pas automatiquement le commit le plus récent : identifiez son message, puis examinez les fichiers concernés. Dans les commandes suivantes, remplacez `` par l’identifiant réel du commit repéré dans votre dépôt.

cd suivi-site
git log --oneline
git show --stat --oneline <identifiant>

La première commande affiche les identifiants abrégés et les messages des commits récents. La seconde indique les fichiers modifiés par le commit ciblé ; vérifiez notamment qu’il ne touche pas à README.md, où votre note locale est conservée.

`git revert` calcule les changements inverses de la version ciblée et les place dans votre travail. L’option `--no-commit` évite de créer immédiatement un commit avec un message généré automatiquement : vous pourrez enregistrer l’annulation avec un message conforme à la convention du projet. Cette méthode ajoute une nouvelle entrée à l’historique au lieu de modifier ou supprimer le commit existant.

git revert --no-commit <identifiant>
git status
git diff --cached

Git prépare les changements inverses du commit ciblé. `git status` distingue ces changements préparés de votre note non préparée dans README.md ; `git diff --cached` montre précisément ce qui sera enregistré comme annulation.

Relisez le diff préparé avant de créer le commit. Vérifiez que seules les modifications inverses attendues y figurent et que la note de `README.md` n’est pas incluse. Si Git signale un conflit, arrêtez-vous : il faut traiter ce cas séparément plutôt que d’enregistrer une annulation dont le contenu n’est pas maîtrisé.

git commit -m "Rétablir la version précédente de la page"
git status
git log --oneline -3

Le nouvel historique comporte un commit d’annulation au-dessus du commit ciblé. Si la note de README.md est toujours présente et non préparée, `git status` la signale encore comme modification locale ; le commit d’annulation ne l’a pas enregistrée.

Dans un historique partagé, les autres personnes peuvent déjà avoir récupéré le commit d’origine. Réécrire l’historique pour le faire disparaître compliquerait la synchronisation de leurs dépôts. Avec un commit d’annulation, chacun peut récupérer une suite de versions commune : l’erreur reste traçable et sa correction est explicite.

Dans cette leçon, le commit d’annulation est créé localement ; vous ne le publiez pas encore. La publication et la vérification sur une forge seront traitées dans les leçons suivantes. Conservez le commit et votre note locale distincts : vous pourrez décider séparément de la suite à donner à cette modification de `README.md`.

• Vérifiez l’identifiant et les fichiers touchés avant toute annulation.
• `git revert` ajoute un commit qui inverse les effets du commit ciblé ; il ne supprime pas celui-ci.
• Relisez les changements préparés et gardez vos modifications locales indépendantes hors du commit d’annulation.
• Un historique partagé se corrige avec un nouveau commit traçable, sans réécrire les versions déjà communiquées.