Annuler la réinitialisation, le rebase et les commits de git : comment récupérer (presque) tout dans Git

Pour annuler git reset, un rebase ou un commit, exécutez git reflog, recherchez l'entrée juste avant l'erreur et pointez votre branche dessus, par exemple avec git reset --hard HEAD@{1}. Git enregistre chaque mouvement de HEAD et de chaque branche dans le reflog, et conserve par défaut même l'entrée d'un commit perdu pendant 30 jours (90 pour les commits toujours sur une branche), donc le travail validé n'est presque jamais disparu. La seule véritable exception est le travail que vous n’avez jamais commis.

Vous trouverez ci-dessous la recette de chaque erreur courante. Chaque commande est purement Git et fonctionne de la même manière sur macOS, Windows et Linux. Sur Windows, exécutez-les dans Git Bash, fourni avec Git for Windows : PowerShell a besoin de noms de reflog tels que HEAD@{1} entre guillemets et n'a pas de grep. À la fin, vous verrez comment GitTree, un client Git de bureau, conserve un instantané de récupération pour 19 types d'opérations afin que la plupart des erreurs reviennent en un seul clic.

Aide-mémoire Git Undo : la commande pour chaque erreur

Trouvez votre situation, puis lisez sa section avant d'exécuter quoi que ce soit. HEAD@{1} signifie « là où se trouvait HEAD il y a un mouvement » ; si vous avez exécuté d'autres commandes depuis, recherchez d'abord le bon numéro avec git reflog.

Git reflog expliqué : le filet de sécurité sous chaque commande

Le reflog (journal de référence) est un journal privé indiquant où HEAD et les astuces de votre branche ont indiqué. Chaque validation, extraction, réinitialisation, fusion, rebase, modification et extraction ajoute une ligne, et les branches de suivi à distance telles que origin/main en obtiennent également une. Il ne réside que dans votre dossier local .git : il n'est jamais poussé et un nouveau clone commence par un vide.

git reflog
git reflog show main
git reflog --date=relative

Un git reflog typique après un rebase ressemble à ceci, l'entrée la plus récente en premier :

6c55495 HEAD@{0}: rebase (finish): returning to refs/heads/feature-login
6c55495 HEAD@{1}: rebase (pick): Validate the email field
cb6e15e HEAD@{2}: rebase (pick): Add the login form
2c44bc3 HEAD@{3}: rebase (start): checkout main
595b83d HEAD@{4}: commit: Validate the email field

Lisez jusqu'à la ligne la plus récente avant l'erreur : ici HEAD@{4}, le commit effectué avant rebase (start). Utilisez son hachage ou ce nom partout où Git attend une validation ; main@{2.hours.ago} fonctionne aussi. Les entrées expirent après 90 jours, ou 30 pour les validations qu'aucune branche ne peut atteindre, et tant qu'une entrée existe, git gc conserve sa validation.

Git annule le dernier commit : réinitialisation logicielle, mixte ou matérielle

Si le commit est toujours uniquement sur votre ordinateur, git reset recule la branche d'un commit. Le mode décide du sort de ses modifications :

git reset --soft HEAD~1
git reset HEAD~1
git reset --hard HEAD~1

• --soft conserve les modifications par étapes, prêtes à être validées à nouveau : idéal pour corriger le message ou ajouter un fichier oublié.
• --mixed, la valeur par défaut, conserve les modifications dans votre dossier de travail, sans préparation, afin que vous puissiez diviser la validation.
• --hard supprime les modifications avec la validation, ainsi que toutes les modifications non validées. Le reflog conserve le commit pendant un certain temps, mais réfléchissez-y à deux fois.

Si vous l'avez déjà poussé, ne le réécrivez pas : git revert HEAD enregistre un nouveau commit qui l'annule. La leçon gratuite Récupérer les erreurs après avoir poussé couvre le retour en arrière et les autres moyens de revenir en toute sécurité.

Annuler git commit --amend

Une modification remplace le commit par un nouveau ; l'original reste dans le reflog. Juste après la mise à jour, git reset --soft HEAD@{1} remet la branche sur l'original et laisse ce que la mise à jour a ajouté. Plus tard, recherchez la ligne commit (amend) dans git reflog et utilisez l'entrée en dessous.

git reset --soft HEAD@{1}

Comment annuler git reset --hard

Une réinitialisation matérielle déplace la branche et écrase vos fichiers, mais les validations supprimées sont toujours dans la base de données d'objets de Git. Le reflog affiche le mouvement comme reset: moving to HEAD~2, et la ligne en dessous correspond à l'endroit où vous étiez. Si la réinitialisation était votre dernière commande, cela ramène tout :

git reflog
git reset --hard HEAD@{1}

git fsck --lost-found

Comment annuler un rebase git

Si le rebase s'est arrêté sur un conflit, git rebase --abort renvoie la branche, l'index et vos fichiers là où ils se trouvaient. Si c'est terminé, vous avez deux chemins pour revenir. Git pointe ORIG_HEAD sur l'ancienne astuce lorsqu'un rebase démarre, donc juste après, git reset --hard ORIG_HEAD l'annule. Le reflog de la branche est encore plus robuste : un rebase déplace la branche une seule fois, à rebase (finish), donc feature-login@{1} est la branche exactement telle qu'elle était. Lorsqu'un rebase ou un Cherry-pick s'interrompt, la leçon Continuer, sauter ou abandonner une opération active explique chaque issue.

git rebase --abort
git reset --hard ORIG_HEAD
git reset --hard feature-login@{1}

Si vous avez poussé la branche rebasée, sa restauration nécessite une poussée forcée (voir ci-dessous). Pour réécrire l'histoire volontairement, lisez notre guide sur le rebase interactif dans une interface graphique Git.

Annuler une fusion git

Une fusion laisse également l'ancienne astuce dans ORIG_HEAD, donc git reset --hard ORIG_HEAD annule celle que vous n'avez pas poussée. Au milieu d'un conflit, git merge --abort vous sort, ou suivez notre guide pour résoudre les conflits de fusion Git. Une fusion poussée est annulée avec git revert -m 1 <merge-commit> ; fusionner à nouveau cette branche plus tard ne ramènera pas ces modifications à moins que vous n'annuliez la restauration.

git merge --abort
git reset --hard ORIG_HEAD
git revert -m 1 <merge-commit>

Récupérer une branche Git supprimée (et une réserve supprimée)

La suppression d'une branche supprime un nom, pas les validations. git branch -D imprime la pointe vers laquelle la branche a pointé, et la création à nouveau de la branche à partir de ce hachage la restaure :

git branch feature-login 1a2b3c4
git reflog | grep "moving from feature-login"

Vous avez perdu cette sortie ? Le reflog de HEAD s’en souvient encore. La deuxième commande trouve checkout: moving from feature-login to main ; l'entrée un numéro plus haut (HEAD@{6} si la correspondance est HEAD@{5}) est le dernier commit de la branche. Si la branche est toujours sur la télécommande, git branch feature-login origin/feature-login est plus rapide. Pour ramener un commit plutôt que la branche entière, appliquez-le avec Cherry-pick.

Récupérer une cachette abandonnée

git stash drop et git stash pop impriment le hachage de la réserve qu'ils ont supprimée, et git stash apply <hash> le ramène. Sans le hachage, la documentation de Git suggère cette recherche de commits de cache inaccessibles ; il trouve les caches enregistrées avec le message par défaut « WIP on… » :

git stash apply 9d668e5
git fsck --unreachable | grep commit | cut -d' ' -f3 | xargs git log --merges --no-walk --grep=WIP --oneline

Comment annuler une poussée forcée

Une poussée forcée remplace la branche distante par la vôtre, donc les validations qui se trouvaient uniquement sur la branche distante en sont supprimées. Votre branche de suivi à distance conserve également un reflog : origin/main@{1} est l'endroit où se trouvait la branche distante avant votre push, comme vous l'avez vu pour la dernière fois, et la sortie push a imprimé le même hachage que la première moitié de old...new.

git reflog show origin/main
git push --force-with-lease origin 1a2b3c4:main

--force-with-lease refuse la poussée si la télécommande a bougé depuis votre dernière récupération, vous ne pouvez donc pas écraser le correctif d'un coéquipier par accident. Les commits que vous n'avez jamais récupérés n'ont jamais été sur votre ordinateur ; celui qui les a poussés peut les pousser à nouveau. Ensuite, parlez-en à tous ceux qui se sont arrêtés entre les deux. La vidéo sur la récupération des erreurs poussées montre l'intégralité de la réparation.

Annuler en un clic dans GitTree : un instantané de récupération pour 19 types d'opérations

Tout ce qui précède fonctionne également dans GitTree : il exécute votre Git installé (2.39 ou plus récent) et son terminal intégré ouvre votre propre shell sous le graphe de validation. Ce qu'il ajoute : GitTree conserve un instantané de récupération sous refs/ogt/trash pour 19 types d'opérations, enregistrant tout ce qu'une étape destructrice supprimerait avant son exécution, et le bouton Annuler dans la barre d'outils inverse la dernière étape.

L'annulation couvre les validations et les modifications, les extractions, les réinitialisations, les rebases (les interactifs également), les fichiers supprimés, les morceaux et les lignes, les branches et les balises supprimées, les fichiers nettoyés non suivis et plus encore. Pour une réinitialisation matérielle exécutée à partir de GitTree, l'instantané contient également vos modifications non validées, que git reset --hard ne peut pas restaurer.

Deux des 19 sont conservés plutôt que inversés. Une poussée forcée modifie une télécommande, que seule une autre poussée peut modifier, donc GitTree conserve la pointe qu'elle a remplacée et vous laisse cette poussée (il pousse toujours de force avec --force-with-lease). Une réserve supprimée est capturée, mais Annuler ne la restaure pas encore. GitTree refuse également une annulation qui écraserait le travail ultérieur et explique pourquoi. Une poussée normale ne peut pas être annulée depuis l'application ; revenir à la place.

Des habitudes qui rendent chaque erreur Git réversible

• Engagez-vous tôt, même de manière désordonnée. Seul le travail validé atteint le reflog ; rangez-le plus tard avec un rebase interactif.
• Branche avant les modifications risquées. git branch backup/before-rebase ne coûte rien et n'expire jamais.
• N'utilisez jamais un simple `--force`. --force-with-lease n'écrasera pas les commits que vous n'avez pas vus.
• Rétablissez l'historique partagé, réinitialisez l'historique privé. Une fois que d'autres personnes ont effectué une validation, annulez-la.
• Gardez Git à jour. GitTree nécessite Git 2.39 ou une version plus récente, et Ubuntu 22.04 est livré avec la version 2.34 ; voir comment mettre à niveau Git sur Ubuntu.

Vous avez toujours le choix entre taper et cliquer ? Lisez Git GUI vs command line, ou commencez par Git pour les débutants, avec une GUI.

GitTree propose un forfait gratuit qui couvre toutes les fonctionnalités de Git, dépôts privés inclus, sur macOS 13 ou version ultérieure, Windows 10 et 11 (x64) et 64 bits Linux (x86_64 : Ubuntu 22.04+, Debian 12+), et Nour, l'assistant IA, est livré avec GitTree Pro (voir tarification). Il a besoin de Git 2.39 ou plus récent et d'un compte GitTree pour se connecter. Obtenez-le depuis la page de téléchargement, ou voyez comment il fonctionne sur Linux.