Annuler un commit Git : soft reset ou revert

Exemple et conditions

L’exemple contient un commit ordinaire, sans merge et avec parent, à la pointe actuelle, arbre propre et sans autre travail indexé. Le premier commit n’a pas de parent HEAD^ ; un merge en a plusieurs. Aucun ne correspond au raccourci. Lisez le graphe plutôt que d’utiliser HEAD~1 comme annulation universelle.

Examiner avant de modifier

Examinez patch, état et partage. Retirer l’enveloppe du commit pour poursuivre le code, inverser un code publié et tout abandonner sont des résultats différents. Coordonnez toute réécriture publiée. Une date récente ou votre nom d’auteur ne prouve pas que le commit est privé.

git status --short
git log -3 --oneline --decorate
git show --stat HEAD

Garder une référence ou un checkout séparé

Créez rescue/before-undo sur HEAD pour garder l’état commité original. Sauvegardez les fichiers non commités à part ; la branche ne les stocke pas. Dans l’exemple propre, soft reset expose uniquement ce patch dans l’index. Un index déjà modifié peut mélanger des tâches et exige sa propre revue.

git branch rescue/before-undo HEAD
SCHOOL_UNDO=$(git rev-parse HEAD)

Premier parcours

Pour le cas local conservant les changements, faites reset --soft HEAD^ et examinez diff --cached. Le contenu reste dans l’index et l’arbre pour un nouveau commit. Reset mixed agit autrement sur l’index. N’utilisez pas --hard simplement pour raccourcir l’état : il modifie aussi les fichiers de travail.

git reset --soft HEAD^
git diff --cached
git status --short

Choisir l’autre résultat consciemment

Pour un commit partagé ordinaire, gardez l’identifiant vérifié dans SCHOOL_UNDO et utilisez revert. Le nouveau commit inverse la modification tout en conservant l’historique reçu. Contrôlez résultat et projet avant un push ordinaire. Un merge exige un parent principal et une compréhension de ses effets futurs : procédure dédiée.

git revert "$SCHOOL_UNDO"

Limites et exceptions

Revert peut rencontrer des conflits avec du travail ultérieur. Lisez status, résolvez et indexez, puis revert --continue. Revert --abort abandonne le mauvais choix. Reset --soft n’a pas d’état correspondant de continuation ou d’annulation. Ne mélangez pas les parcours avec un revert encore actif.

git status
git revert --abort

Conflits et nettoyage

Abandonner aussi le code commité et les fichiers locaux est une décision destructive supplémentaire. Préservez l’état d’abord. Le travail non commité n’est pas dans reflog. Avec restore points activés et changements locaux détectés, FluxGit peut créer un safety stash avant un hard reset couvert ; ce terminal n’appelle pas ce parcours protégé.

Vérifier le résultat

Après soft reset, comparez pointe et patch indexé au secours. Après revert, vérifiez que l’inverse touche seulement le comportement voulu et conserve le travail ultérieur utile. Effectuez les contrôles du projet. Gardez le secours pendant la revue : une commande terminée sans erreur ne prouve pas la justesse du code.

git log -4 --oneline --decorate
git status --short
git diff --cached

Questions fréquentes

Soft reset supprime-t-il les fichiers ? Il conserve arbre et index en déplaçant la référence. Revert efface-t-il l’original ? Non, il ajoute un inverse. Reflog récupère-t-il tout ? Non : il concerne références locales retenues et objets commités, pas le contenu arbitraire des fichiers non enregistrés.

Examiner l’opération dans FluxGit

Utilisez l’historique visuel et la vue des modifications de FluxGit pour examiner l’opération et les commits concernés. Gardez les vérifications de branche, de partage et de fichiers locaux de cet exemple. La page de téléchargement présente les builds et plateformes disponibles.

Références officielles Git

• git-reset
• git-revert
• git-reflog