git revert contre git reset — une question décide

■ espace · voie prose

LA DÉMO DU DÉPÔT JETABLE

Deux minutes dans un dépôt de passage, et la différence n'est plus une définition — c'est un log que vous avez vu :

git init /tmp/revert-vs-reset && cd /tmp/revert-vs-reset
echo one > file.txt && git add . && git commit -m "one"
echo two > file.txt && git add . && git commit -m "two"

git revert --no-edit HEAD
git log --oneline
# 1a2b3c4 (HEAD -> main) Revert "two"   ← the cancellation
# 5d6e7f8 two                          ← still in the log
# 9f8e7d6 one

git reset --hard HEAD~1
git log --oneline
# 9f8e7d6 one                          ← "two" is unreachable

verify: après le revert git log --oneline → 3 commits · après le reset → 1 commit — l'asymétrie est toute la réponse

LES TROIS MODES DE RESET

Les modes contrôlent où vos changements survivent après que le pointeur bouge — et une seule rangée de cette table supprime du travail :

• git reset --soft HEAD~1 — « J'ai committé trop tôt. » Tout retourne en staged, prêt pour un re-commit.
• git reset HEAD~1 (mixed) — « J'ai stagé les mauvais fichiers. » Les éditions survivent dans l'arbre de travail, rien de stagé. Accouplez-le d'un clean si vous voulez aussi les fichiers égarés partis.
• git reset --hard HEAD~1 — « Ce commit et mes éditions non-commitées sont à la poubelle. » Git ne demandera pas deux fois ; aucun undo pour la partie arbre-de-travail, sauf si vous l'aviez stashé ou commité d'abord.

verify: git reset --soft HEAD~1 → git status montre le changement « to be committed » · --mixed → « changes not staged »

revert n'a pas de modes parce qu'il ne détruit jamais rien — il ne fait qu'ajouter un commit compensatoire.

LA SEULE QUESTION

Quelqu'un d'autre a-t-il tiré ce commit ? Si oui, reset est hors table. Reseter une branche sur laquelle d'autres ont basé du travail réécrit l'historique partagé : leur prochain pull rencontre des branches divergentes, et le « correctif » est en général un force-push qui transforme votre erreur en problème de tout le monde. Revert ajoute un commit normal, donc un simple git pull fusionne proprement pour tout le monde — voilà pourquoi revert est la réponse par défaut sur main et sur les pull requests GitHub, où le bouton « Revert » existe précisément parce que réécrire l'historique d'une PR fusionnée n'est pas une option.

Reset, c'est pour la fenêtre avant de partager : le commit d'il y a trente secondes, la maladresse de staging, la branche d'expérimentation locale. Si la seule copie du travail vit sur votre machine, vous êtes libre de réarranger l'historique — c'est tout le sens de la fenêtre pré-push. Cas intermédiaire : vous avez poussé sur votre propre branche feature et personne n'embarque dessus — un force-push après reset est socialement acceptable là, mais revert coûte toujours moins de coordination. Réservez les force-push aux branches que vous possédez seul.

Revert est aussi plus sûr structuralement, pas juste par convention : le revert produit un commit ordinaire — la CI tourne dessus, le diff est lisible en revue, et git log explique au vous-du-futur pourquoi le changement a disparu. Reset jette l'état intermédiaire en silence ; personne qui revoit après ne peut voir ce qui a été défait ou quand.

DEUX TRANCHANTS SUR REVERT

• Reverter un commit de fusion exige git revert -m 1 <sha> — une fusion a deux parents, donc « défais-la » est ambigu ; -m 1 garde la ligne dans laquelle vous avez fusionné. Sans, git refuse. Piège de suivi : re-fusionner la même branche ensuite paraît déjà-appliqué à git, donc ré-atterrir ce travail veut dire reverter le revert.
• Revert n'est pas une machine à remonter le temps — il défait le diff d'un seul commit. Si des commits postérieurs ont touché les mêmes lignes, vous aurez peut-être des conflits à résoudre : git vous dit que la défaisance est entortillée — information utile, pas une panne.

OÙ RESTORE A SA PLACE

git restore (et git switch, son binôme) sont arrivés dans git 2.23 pour reprendre les jobs que reset faisait mal par surcharge de nom :

La découpe moderne : restore répare des fichiers, reset déplace des branches, revert défait des commits publiés. C'est un seul modèle mental découpé en trois commandes. Les vieilles formes de git checkout marchent encore partout ; les nouvelles formes vous empêchent seulement d'envoyer toute une branche au déchiqueteur quand vous vouliez déstager un fichier.

LE BILAN

1. Commit public (poussé, d'autres ont tiré) → git revert <sha>.
2. Commit local-seulement, vous voulez le refaire → git reset --soft ou --mixed et recommettez.
3. Local-seulement, le sortir avec le bazar non-commité → git reset --hard, après un vrai regard à ce que l'arbre de travail contient d'autre.
4. Un fichier s'est fait abîmer → git restore <file> et laissez la branche tranquille.

verify: git reflog → HEAD@{n} liste la position d'avant-reset — git reset --hard HEAD@{1} y retourne

La seule entrée vraiment dangereuse de cette liste est --hard — tout le reste se ravive avec git reflog — qui se souvient des commits détachés pendant ~90 jours. Les pertes permanentes dans git sont étroites et exigent pour la plupart que vous tapiez explicitement ; l'habitude qui vaut la peine se construirait en marquant une demi-seconde avant --hard, pas en évitant complètement les outils tranchants de git. Et si tout le menu de défaisance vous semble de la cérémonie, la critique est honnête — jujutsu, le VCS compatible git, redessine exactement ce morceau.

fin du duo de défaisance · rien n'a été téléchargé · tout est local