Git : annuler un commit déjà poussé avec revert, sans réécrire l’historique partagé

Un commit est parti sur la branche partagée, et il faut annuler son effet. Pour un commit ordinaire, hors commit de merge, git revert ajoute un commit inverse sans retirer l’original de l’historique. C’est un point de départ adapté au travail en équipe, à condition de vérifier ce que l’annulation change réellement.

Ce guide traite un seul commit déjà intégré à la branche cible. Il ne couvre ni la réécriture d’historique ni le retour arrière d’une base de données en production. Exécutez chaque commande séparément et arrêtez-vous à la première erreur.

1. Vérifier le dépôt et préserver le travail en cours

git status

Lisez le résultat avant toute modification : fichiers modifiés, changements indexés, fichiers non suivis et éventuelle opération en cours. Terminez ou mettez à l’abri votre travail selon les pratiques du projet. Ne lancez pas une nouvelle annulation au milieu d’un merge, d’un rebase ou d’un autre revert.

Pour cette procédure, partez d’un répertoire de travail propre. N’utilisez pas une commande de suppression des changements pour obtenir artificiellement cet état.

2. Créer une branche depuis la référence distante actualisée

Les exemples supposent un dépôt distant nommé origin et une branche cible main. Adaptez ces noms au projet. Choisissez aussi un nom de branche d’annulation qui n’existe pas encore.

git fetch origin

fetch récupère les objets et actualise les références de suivi distant selon la configuration du dépôt ; il ne fusionne pas leur contenu dans votre branche courante. Vérifiez que la récupération réussit avant de continuer.

git switch -c revert/annulation-cible origin/main

Cette commande crée une branche locale depuis origin/main et vous y place. Elle évite de partir, par inadvertance, de commits locaux supplémentaires sur votre propre branche main. Elle modifie néanmoins les fichiers de travail : contrôlez de nouveau git status.

3. Identifier précisément le commit à annuler

Remplacez SHA_DU_COMMIT par l’identifiant réel, vérifié dans l’historique de la branche cible. Ce texte est un repère, pas une valeur à copier telle quelle.

git show --stat SHA_DU_COMMIT
git show SHA_DU_COMMIT

La première commande résume les fichiers touchés ; la seconde permet de lire le correctif. Vérifiez le contenu, pas seulement le titre du commit. Consultez ces sorties localement : un diff peut contenir des données sensibles.

Demandez-vous surtout si d’autres changements reposent sur celui-ci. Par exemple, retirer une fonction alors que du code récent l’appelle exige une analyse fonctionnelle, même si Git n’affiche aucun conflit.

4. Produire et relire le commit inverse

git revert SHA_DU_COMMIT

Sans conflit, Git prépare le commit inverse et ouvre normalement l’éditeur de message. Conservez la référence au commit annulé et expliquez pourquoi vous intervenez. Cette opération n’est pas une restauration automatique de tout le projet à une ancienne date.

git show --stat HEAD
git show HEAD
git diff --check HEAD^ HEAD

Relisez le nouveau commit. Le dernier contrôle repère notamment des erreurs d’espacement et des marqueurs de conflit introduits dans le diff ; il ne valide pas le comportement du logiciel.

Lancez ensuite les tests documentés par le projet, puis vérifiez le scénario à l’origine du problème et un scénario voisin. Il n’existe pas de commande de test universelle : une compilation réussie, à elle seule, ne démontre pas que le service fonctionne.

Que faire si git revert rencontre un conflit ?

Consultez git status, corrigez les fichiers concernés et indexez uniquement les résolutions relues. Le chemin ci-dessous est à remplacer :

git add chemin/du/fichier
git revert --continue

Pour abandonner l’annulation en cours plutôt que la poursuivre :

git revert --abort

Cette dernière commande revient à l’état précédant l’opération. Sauvegardez ailleurs toute résolution que vous souhaitez conserver avant de l’utiliser. Ne lancez pas les deux options successivement comme une recette.

Attention : un commit de merge demande une autre analyse

Un merge possède plusieurs parents. Son annulation nécessite de choisir le parent de référence avec l’option -m ; recopier -m 1 sans comprendre le graphe n’est pas une méthode sûre.

Autre piège : annuler un merge ne retire pas ses commits de l’ascendance. Une fusion ultérieure de la même branche ne réintroduit donc pas automatiquement tout le contenu annulé. Faites relire ce cas et préparez un plan de réintégration ; le chapitre Pro Git cité en sources détaille ce comportement.

5. Publier la branche après validation

Une fois le résultat relu et testé, si vous avez l’autorisation de publier sur ce dépôt :

git push -u origin revert/annulation-cible

Ce push transmet la branche d’annulation et configure son suivi distant. Il ne l’intègre pas à main. Ouvrez ensuite une pull request ou une merge request selon le fonctionnement de l’équipe, avec le motif, les contrôles réalisés et les limites connues.

Vérifiez auparavant les automatismes du dépôt : publier une branche peut déclencher une CI ou un déploiement. Si le push est refusé, examinez la cause et les protections ; ne forcez pas l’envoi pour contourner le refus.

À retenir

Une annulation technique doit avoir un résultat attendu et vérifiable. Avant de fusionner, confirmez aussi ce qui se passe hors du dépôt : un changement de code ne remet pas, à lui seul, des données migrées dans leur état précédent. Gardez cette vérification dans la revue, pas seulement dans votre tête.

Sources

• Git — revert : annulation, conflits et abandon.
• Git — status : état du répertoire de travail et de l’index.
• Git — fetch et switch : création et changement de branche.
• Git — show et diff : inspection et option –check.
• Git — push : publication et suivi distant.
• Pro Git — Advanced Merging : annulation d’un merge et fusion ultérieure.