> git undo, cancel, revert — garde tes modifications, quelle que soit l'orthographe▋

Git embarque cinq verbes pour récupérer ton code — undo, cancel, revert, reset, restore — et aucun ne s'appelle réellement undo. Quelque part, un dictionnaire des synonymes est très fier de lui.

Voilà ce que coûte le dictionnaire. La semaine dernière, la requête tête de cette famille — git undo last commit keep changes — a tiré 73 impressions en position 11.1 sans un seul clic, avec une croissance de +100% d'une semaine sur l'autre, escortée de quatre cousins orthographiés différemment. Les gens ne sont pas confus face à git. Ils ont peur de --hard, et chaque tutoriel générique répond à cette peur par le seul flag qui la confirme. Cette page parcourt la famille de haut en bas : choisis ton verbe, vérifie le tableau, et seulement ensuite touche à l'historique.

Verbe tapé	Ce que git fait vraiment	Garde le travail ?	La commande
"undo"	L'étiquette de branche recule d'un commit ; les modifications reviennent stagées	Oui — dans l'index	git reset --soft HEAD~1
"cancel"	Reset par défaut : l'étiquette recule, les modifications reviennent mais non stagées	Oui — dans le working tree	git reset HEAD~1
"revert"	Un nouveau commit est ajouté qui annule l'ancien ; l'historique n'est jamais réécrit	Oui — en diff inverse	git revert HEAD
"unstage"	Les chemins sortent de l'index ; le contenu des fichiers reste intact	Oui — rien n'a quitté le working tree	git restore --staged file.txt
"je le mets de côté"	Le travail est emballé et posé sur une étagère où tu pourras le reprendre	Oui — sur la pile de stash	git stash push -m "wip"

La seule décision qui compte

• Repère le commit : git log --oneline -3
• Pose la seule question : quelqu'un d'autre l'a-t-il tiré ?
• Pas poussé → git reset --soft HEAD~1, re-committe proprement
• Poussé → git revert HEAD, pousse l'inverse
• Lance git status ensuite pour confirmer que ton travail est où tu l'attends

Comment annuler mon dernier commit en gardant les modifications ?

git reset --soft HEAD~1 — l'étiquette de branche recule d'un commit et tout ce que tu as fait revient stagé. Rien n'est supprimé, rien ne quitte l'index ; tu peux re-commiter avec un meilleur message ou découper le travail. Le parcours complet, cas poussé compris, est dans git undo last commit : keep changes, stay safe.

verify : après le reset, git status doit montrer tes fichiers stagés sous « Changes to be committed » — c'est ton travail, qu'on te rend.

« git undo commit keep changes » veut dire quelque chose d'autre ?

Non — même question, même réponse. « Undo » n'a jamais été une commande git ; notre tableau montre les deux orthographes visant des problèmes identiques, et les deux se résolvent en reset --soft. Quand les gens disent undo, ils veulent dire déplace l'étiquette, garde le travail — la seule chose qu'un soft reset a jamais faite.

Pourquoi « git revert last commit keep changes » a-t-il une réponse différente ?

Parce que revert est le seul membre de la famille qui ajoute de l'historique au lieu de le rembobiner. git revert HEAD crée un nouveau commit dont le diff annule l'ancien — le « garde les modifications » est automatique, puisque le mauvais commit reste dans le registre et que le working tree finit sans lui. C'est le bon outil dès que quelqu'un d'autre a tiré ; la fourche reset-vs-revert est cartographiée dans git revert vs reset : which one saves your history?

Revert = l'annulation publique. Elle ne réécrit jamais ce que les autres ont déjà ; elle annule le changement par un nouveau commit additif.

« git cancel commit » est une vraie commande ?

Non — cancel est du langage parlé, et la traduction git du langage parlé, c'est reset. « Cancel commit but keep changes » et « cancel last commit but keep changes » — deux orthographes de plus, la même semaine sur notre tableau — retombent toutes deux sur git reset --soft HEAD~1. Git ne se soucie que de l'étiquette que tu déplaces et du flag que tu passes ; le vocabulaire, c'est toi qui l'apportes.

Puis-je supprimer un commit que personne n'a tiré ?

Oui — un commit non poussé t'appartient encore, tu peux le remodeler sans conséquences. reset --soft garde le travail, reset HEAD~1 le garde non stagé, et seul --hard le jette — le seul verbe sans garde du travail sur cette page. Si le commit n'a jamais été à toi et que rien ne le référence, git gc est ce qui finira par le ramasser, pas toi.

Peut-on stasher un seul fichier avec git ?

Oui — git stash push -m "wip" -- src/app.ts met un seul chemin de côté et laisse le reste de ton arbre tranquille. Le séparateur -- est ce qui limite le stash aux chemins nommés. Les cas limites du fichier unique — y compris pourquoi le stash survit à un checkout — vivent dans git stash a single file without losing the rest.

Peut-on cherry-picker plusieurs commits ?

Oui — une plage : git cherry-pick A^..B prend chaque commit après A jusqu'à B inclus, dans l'ordre. Ajoute -n si tu les veux stagés en un seul bloc au lieu de commités un par un. Le manuel des conflits pour les plages pénibles est dans git cherry pick : multiple commits, branches, conflicts.

Comment cherry-picker plusieurs commits depuis une autre branche ?

La même forme de plage marche entre branches : git switch target && git cherry-pick A^..B. Git résout les commits depuis la branche source et les rejoue sur la tienne — attends-toi à des conflits là où les branches ont divergé, et traite-les un par un plutôt qu'en bloc.

Puis-je récupérer un commit abandonné ?

Presque toujours oui — le reflog se souvient de où HEAD est passé pendant environ 90 jours par défaut (le gc.reflogExpire de git). Trouve le hash abandonné avec git reflog, puis git reset --soft HEAD@{1} pour le remettre sous ton working tree. Tu n'annules rien — tu déplaces une étiquette pendant que git garde tranquillement ses reçus.

Quel undo git devrais-je utiliser ?

Celui du tableau ci-dessus, honnêtement — mais si tu veux que la machine choisisse : le générateur git-undo prend ton désordre en entrée et imprime la commande exacte, et son post de lancement montre le raisonnement cas par cas. Chaque récupération testée de ce cluster est rangée sur le hub git-undo.

Le piège dans la pièce : --soft, --mixed, --hard

Le flag décide où atterrit ton travail, et un seul des trois est dangereux. --soft le rend stagé, --mixed (le défaut) non stagé, --hard aligne tout sur le commit cible et jette le reste. Si tu as déjà tapé --hard en panique : le reflog garde encore le commit pendant ~90 jours — git reflog, puis reset vers le hash. Le verbe tapé dans les cinq premières secondes ne décide rien pour toujours ; le journal de git est plus long que ton regret.

Quelle orthographe t'a amené ici — undo, cancel ou revert ? Dis-le en commentaire ; le générateur prend les trois, et la plus étrange devient le prochain post. Le tableau dit que la plupart ont tapé undo — la donnée était là avant le conseil.