git reset, revert et stash : annuler proprement

Il n'existe pas une seule façon d'annuler du travail dans Git, et confondre git reset revert avec git stash est l'une des sources de confusion les plus fréquentes. Les trois donnent une impression d'« annulation », mais font des choses très différentes : l'un met les modifications de côté pour plus tard, l'un rembobine l'historique, et l'un crée un nouveau commit qui inverse un changement sans toucher au passé. Savoir lequel choisir, c'est la différence entre perdre une soirée de travail et garder un historique propre.

Trois commandes, trois objectifs différents

Clarifions d'abord le modèle mental. Git comporte trois zones : le répertoire de travail, l'index (zone de staging) et l'historique des commits (HEAD). Ce qui distingue ces commandes, c'est laquelle de ces zones elles modifient.

• git stash — met de côté les modifications non validées du répertoire de travail et de l'index, et ramène l'arborescence au dernier commit. Rien n'est détruit ; vous pourrez les récupérer plus tard.
• git reset — déplace HEAD (et, au choix, l'index et le répertoire de travail) vers un autre commit. Il réécrit l'historique.
• git revert — crée un nouveau commit qui annule l'effet d'un commit antérieur. L'historique reste intact, avec une « annulation » ajoutée par-dessus.

git stash : mettre un travail en cours de côté en toute sécurité

Vous êtes à mi-parcours d'une fonctionnalité quand vous devez soudain changer de branche pour livrer un correctif urgent, mais votre travail n'est pas prêt à être validé. C'est précisément le rôle de git stash.

git stash push -m "formulaire de filtre inachevé"
# l'arborescence est propre, changez de branche, faites le hotfix...
git stash list
git stash pop      # restaure le dernier stash et le retire de la liste
git stash apply    # restaure mais le conserve dans la liste

Utilisez git stash -u pour inclure aussi les fichiers non suivis. Avec plusieurs stash, vous pouvez en cibler un par index, par exemple git stash pop stash@{1}. Un stash est comme une poche temporaire : vous mettez le travail de côté sans valider ni salir la branche. Ce n'est cependant pas un stockage à long terme : plutôt que de laisser du travail en stash pendant des jours, ouvrir un commit WIP est plus sûr.

git reset : rembobiner HEAD

git reset est la commande la plus puissante et la plus mal comprise. Ses trois modes correspondent à trois niveaux de sévérité :

• --soft — déplace seulement HEAD. Vos modifications restent dans l'index, comme si vous veniez de faire git add. Idéal pour regrouper les derniers commits en un seul.
• --mixed (par défaut) — déplace HEAD et réinitialise l'index. Les modifications restent dans le répertoire de travail, « non indexées ».
• --hard — réinitialise HEAD, l'index et le répertoire de travail d'un coup. Tout ce qui n'est pas validé est perdu.

# Regrouper les 3 derniers commits en un seul (sans perdre les modifications)
git reset --soft HEAD~3
git commit -m "fonctionnalité de filtre"

# Désindexer un fichier ajouté par erreur (contenu intact)
git reset HEAD fichier.php

# ATTENTION : forcer le retour de l'arborescence au dernier commit
git reset --hard HEAD

La règle d'or : n'utilisez git reset que sur des commits que vous n'avez pas encore partagés (poussés). Si vous supprimez des commits avec reset sur une branche partagée puis poussez avec --force, l'historique de tous les autres diverge du vôtre.

git revert : annuler un historique partagé en toute sécurité

Si un mauvais commit est déjà arrivé sur main et que d'autres l'ont récupéré, vous ne pouvez pas effacer l'historique. git revert est l'outil approprié ici : il ajoute un nouveau commit qui inverse tout ce que le mauvais commit a fait.

# Annuler un commit précis
git revert a1b2c3d

# Annuler un commit de fusion — indiquez la ligne principale à conserver
git revert -m 1 <merge-sha>

# Appliquer le changement inverse sans créer de commit
git revert --no-commit a1b2c3d

Revert ne casse pas l'historique, ce qui en fait le choix le plus sûr en équipe et sur les branches de production. Plutôt que de réécrire la chronologie pour une erreur que tout le monde peut voir, vous laissez une trace honnête qui dit « j'ai annulé ce commit ».

Lequel, et quand ?

• Mettre un travail à moitié fait de côté pour changer de branche → stash
• Regrouper ou nettoyer des commits non encore poussés → reset --soft ou git commit --amend
• Retirer de l'index un fichier indexé par erreur → reset (mixed)
• Tout ramener localement au dernier commit → reset --hard (prudence)
• Annuler un commit partagé/poussé → revert

Si vous avez supprimé par accident : le reflog vous sauve

Les commits que vous croyez perdus à cause de git reset --hard sont généralement toujours là. Git enregistre chaque déplacement de HEAD dans le reflog :

git reflog
# trouvez le sha du commit cible dans la sortie, puis :
git reset --hard a1b2c3d
# ou récupérez le commit perdu dans une nouvelle branche
git branch recuperation a1b2c3d

Les entrées du reflog sont conservées 90 jours par défaut ; avant de paniquer, consultez donc toujours d'abord le reflog.

Questions fréquentes

Puis-je récupérer des fichiers perdus avec git reset --hard ?

Si la modification perdue avait été validée auparavant, oui : retrouvez le commit avec git reflog et revenez-y. Mais les modifications jamais validées, qui ne vivaient que dans le répertoire de travail, sont supprimées définitivement par --hard ; le reflog ne peut pas les récupérer.

Puis-je faire un reset après un push ?

Techniquement oui, avec --force, mais ne le faites pas sur des branches partagées. Si d'autres ont récupéré ces commits, l'historique se scinde. Utilisez plutôt git revert ; il donne le même résultat sans risque.

Quelle est la différence essentielle entre stash et reset ?

Stash sert à sauvegarder des modifications et à les restituer plus tard sans toucher à l'historique. Reset déplace réellement HEAD et l'index. Si vous mettez un travail de côté « pour continuer plus tard », pensez stash ; si vous modifiez l'historique, pensez reset.

Clarifions votre stratégie d'annulation. Vous voulez une configuration solide pour votre flux Git, votre gestion des versions ou votre pipeline CI/CD ? Contactez-moi et nous construirons ensemble le workflow le plus sûr pour votre projet.