mrsaynothing.dev
git undo keep changes — la FAQ pour chaque orthographe d'effarés
La FAQ pour chaque orthographe de « défaire mon commit mais garder le travail » — une commande répond à la famille, et le seul drapeau qui supprime du travail n'est jamais requis.
■ space · couloir de prose · foire aux questions
Une commande répond à toute la famille — git reset --soft HEAD~1 recule l'étiquette de branche d'un commit et vous rend votre travail déjà indexé.
Undo, cancel, revert ne sont pas trois fonctions de git. Deux d'entre eux sont le même reset sous des accents différents ; revert est l'original parce qu'il ajoute de l'historique au lieu de le rembobiner.
Déjà poussé ? Revert, jamais de réécriture — quiconque a tiré détient les vieux commits.
git reset --soft HEAD~1 est la réponse à chaque orthographe de keep-changes : l'étiquette de branche recule d'un commit et votre travail revient indexé, prêt à re-commiter. Le commit est déjà poussé ? Utilisez git revert HEAD à la place — il ajoute un commit inverse et ne réécrit rien.LE TABLEAU DES VERBES
Chaque mot que les gens tapent, ce que git fait réellement, et si le travail survit :
| Verbe tapé par les gens | Ce que git fait réellement | Garde le travail ? | La commande |
|---|---|---|---|
| « undo » | L'étiquette de branche recule d'un commit ; les changements reviennent indexés | Oui — dans l'index | git reset --soft HEAD~1 |
| « cancel » | Reset par défaut : l'étiquette recule, les changements reviennent mais non indexés | Oui — dans l'arborescence de travail | git reset HEAD~1 |
| « revert » | Un nouveau commit est ajouté qui défait l'ancien ; l'historique n'est jamais réécrit | Oui — sous forme de diff inverse | git revert HEAD |
| « unstage » | Les chemins quittent l'index ; le contenu des fichiers est intact | Oui — rien n'a quitté l'arborescence | git restore --staged file.txt |
| « remise pour l'instant » | Le travail est emboîté et posé sur une étagère où le reprendre plus tard | Oui — sur la pile de stash | git stash push -m "wip" |
La seule décision qui compte : quelqu'un l'a-t-il tiré ?
Non — c'est encore à vous : git reset --soft HEAD~1. L'étiquette recule, votre travail revient indexé. Oui — quelqu'un l'a tiré : git revert HEAD. L'historique gagne un commit inverse ; rien de ce que quiconque a tiré n'est réécrit. Dans les deux cas le travail survit — le choix ne porte que sur la copie de l'historique qui reste vraie. Et si le drapeau qui vous effraie est --hard : c'est le seul membre de la famille qui supprime du travail, et il n'est jamais requis pour garder les changements. Vous avez trouvé cette page précisément pour ne jamais devoir le taper.
Que garde réellement --soft ?
Tout, indexé. Le commit quitte la branche, le diff revient dans l'index exactement tel qu'il a été committé, et git status affiche « changes to be committed ». Réparez ce que vous vouliez réparer et re-commitez — ou ajoutez d'abord plus de travail. C'est un pas avant --amend : amend réécrit le dernier commit sur place ; soft le défait et vous attend.
Amend est-il un undo ?
Un petit undo, pour le dernier commit seulement. git commit --amend --no-edit replie les changements indexés dans le commit que vous venez de faire — parfait pour le fichier oublié. La règle de la section pushed-commit s'applique encore : amender un commit poussé réécrit l'historique, donc sur une branche partagée, préférez revert.
Quand --hard est-il réellement la bonne réponse ?
Quand vous voulez que l'arborescence de travail corresponde exactement à un commit, et que vous avez regardé ce qui sera perdu. git reset --hard HEAD~1 rejette le commit et les modifications non commitées en un seul mouvement — git ne demandera pas deux fois. Le rituel de sécurité tient en une ligne : git branch backup-before-reset d'abord ; les branches sont gratuites. Et si vous l'avez déjà exécuté, git reflog se souvient de l'endroit où était HEAD pendant environ 90 jours — git reset --hard HEAD@{1} le ramène en arrière.
Comment jeter les modifications d'un seul fichier ?
git restore file.txt — l'orthographe moderne de l'ancien git checkout -- file. Il rejette les modifications d'arborescence de ce seul chemin et ne touche à rien d'autre : aucun mouvement de branche, aucun changement d'indexation. Pour ramener un fichier à un commit précis : git restore --source <sha> file.txt.
Où stash se place-t-il dans la famille ?
Stash est le seul verbe qui emboîte le travail au lieu de le repositionner. git stash push -m "wip" pose vos modifications sur l'étagère et vous rend un arbre propre ; git stash pop les ramène. C'est le bon outil quand il faut changer de branche en plein milieu d'une tâche — et il accepte un pathspec, si bien qu'un seul fichier peut être remisé pendant que le reste reste sale.
J'ai déjà exécuté la mauvaise commande. Le travail est-il perdu ?
Presque jamais. Reset déplace une étiquette ; revert ajoute un commit ; aucun ne supprime d'objets. git reflog liste tous les endroits où HEAD est passé pendant ~90 jours — trouvez l'entrée d'avant l'erreur et git reset --hard HEAD@{n} vous y ramène. L'ensemble réellement irrécupérable est étroit : les fichiers non suivis supprimés par git clean -f, et les entrées de reflog au-delà de leur horloge.
fin de la famille de verbes · rien de téléchargé · tout en local