Rebase Git raté : retrouver ses commits avec reflog

TL;DR Un commit a disparu après un rebase ? Retrouvez l’ancienne pointe avec git reflog, protégez les deux états et rétablissez votre branche locale si nécessaire.

Vous venez de terminer un rebase et un commit a disparu de git log ? Commencez par retrouver l’ancienne pointe de votre branche dans git reflog, puis créez une branche de secours dessus. Vous pourrez vérifier vos commits avant de toucher à la branche d’origine.

Je prends le cas d’une branche locale de travail, fonctionnalite, dont le rebase est parti de la mauvaise base ou a laissé un commit de côté. Remplacez ce nom par celui de votre branche et utilisez les identifiants de votre dépôt, pas ceux de mon exemple.

Le rebase est-il encore en cours ?

Dans le dépôt concerné, commencez par regarder ce que Git est en train de faire :

git status

Si Git indique qu’un rebase est en cours et que vous voulez l’abandonner, utilisez la commande prévue pour ce cas. Avant de la lancer, copiez à part les résolutions de conflit ou les modifications faites depuis le début de l’opération si vous souhaitez les conserver.

git rebase --abort

Git revient alors à l’état de départ du rebase. Contrôlez de nouveau avec git status. En revanche, si le rebase est déjà terminé, --abort ne peut plus revenir en arrière. C’est dans ce cas que le journal local devient utile. Le manuel de git rebase détaille la différence entre abandonner et quitter un rebase.

Garder une copie de l’état actuel

Avant toute restauration, vérifiez que vous êtes bien sur la branche de travail. La première commande doit afficher son nom. Si elle ne renvoie rien, vous êtes en HEAD détachée : identifiez d’abord la branche concernée, plutôt que de reprendre la suite telle quelle.

SUR LA CHAÎNE · NOUVELLE VIDÉO Le NAS 4 baies le plus petit ET le plus puissant que j’ai testé (Beelink ME Pro) et dopé à l'IA Voir la vidéo →

git branch --show-current
git branch secours-apres-rebase HEAD

La seconde commande donne un nom au commit actuel, sans changer de branche ni modifier les fichiers. Si le nom de secours existe déjà, choisissez-en un autre. Cette branche conserve les commits de l’état actuel, y compris ceux ajoutés depuis le rebase, mais elle ne sauvegarde pas les fichiers modifiés ou non suivis. Mettez ces fichiers à l’abri avant de changer de branche.

Retrouver le commit d’avant le rebase

git log suit les parents des commits. Le reflog, lui, enregistre les déplacements des références dans ce dépôt. Regardez d’abord celui de la branche : il est généralement moins encombré que celui de HEAD, qui inclut aussi les changements de branche.

git reflog show -n 12 fonctionnalite

Voici un extrait raccourci d’un essai réalisé dans un dépôt de test. Le rebase a rejoué « Ajouter les tests », mais le commit « Ajouter le filtre » n’est plus dans l’historique courant.

14ed6bd fonctionnalite@{0}: rebase (finish): …
9e66107 fonctionnalite@{1}: commit: Ajouter les tests
00969b2 fonctionnalite@{2}: commit: Ajouter le filtre

Le commit à récupérer est 9e66107 : c’est la pointe juste avant ce rebase, et « Ajouter le filtre » fait partie de son historique. Prendre directement 00969b2 laisserait le commit de tests de côté. Si vous avez travaillé depuis, l’index ne sera pas forcément @{1}. Repérez l’entrée du bon rebase, lisez l’état précédent et copiez son identifiant.

Si vous ne retrouvez pas l’opération, affichez davantage d’entrées ou consultez git reflog -n 30. Dans le journal de HEAD, cherchez le début du rebase et examinez l’état immédiatement antérieur à son démarrage. La ligne rebase (start) peut déjà pointer vers la nouvelle base. ORIG_HEAD est un indice supplémentaire, mais d’autres commandes peuvent l’avoir remplacé.

Vérifier la récupération sur une branche séparée

Inspectez le commit repéré avant de le nommer. Remplacez 9e66107 par votre identifiant et ne lancez la deuxième commande que si la première montre bien le commit attendu.

git show --stat 9e66107
git branch secours-avant-rebase 9e66107
git log --oneline -n 8 secours-avant-rebase

Vérifiez que les commits recherchés apparaissent dans le résultat. Vous pouvez ensuite comparer les deux versions du projet sans changer de branche :

git diff --stat secours-apres-rebase secours-avant-rebase
git diff secours-apres-rebase secours-avant-rebase

Le diff compare les fichiers aux deux pointes. Il peut aussi faire apparaître des changements venus de la base du rebase : il ne représente pas forcément le seul commit manquant. Si vous voulez seulement reprendre votre travail, un git switch secours-avant-rebase suffit, une fois vos modifications locales mises à l’abri.

Rétablir le nom de la branche si nécessaire

Si fonctionnalite est une branche locale non partagée et que vous voulez lui rendre exactement son ancienne pointe, gardez les deux branches de secours. Vérifiez que secours-apres-rebase pointe toujours vers l’état que vous vous apprêtez à remplacer. Si la branche a avancé, créez un nouveau point de secours. Le dossier de travail doit être propre avant de poursuivre : git status --short ne doit rien afficher. Contrôlez aussi qu’aucune opération Git n’est en cours avec git status.

git switch --detach
git branch -f fonctionnalite secours-avant-rebase
git switch fonctionnalite

Exécutez les lignes une à une et arrêtez-vous si Git signale une erreur. La première quitte la branche sans changer de commit. La seconde déplace volontairement la référence locale, ce que Git refuse si la branche est ouverte dans un autre arbre de travail. La dernière revient sur la branche rétablie. Vérifiez git log --oneline -n 8 et lancez les tests du projet. L’état d’après rebase reste accessible par sa branche de secours.

Si le rebase a déjà été poussé sur une branche utilisée par d’autres, gardez la récupération séparée et mettez-vous d’accord sur les commits à réintégrer. Une restauration locale ne change rien au serveur. Un push forcé risquerait, lui, d’écraser des changements distants.

Questions fréquentes

Pourquoi mon commit n’apparaît-il plus dans git log ?

Le rebase rejoue des commits et peut leur donner de nouveaux identifiants. Un commit absent de la branche courante peut encore exister et être retrouvé dans le reflog local.

Le reflog récupère-t-il des fichiers jamais commités ?

Non. Il journalise les mouvements de références. Pour des fichiers jamais enregistrés dans un commit, cherchez plutôt une sauvegarde ou l’historique de votre éditeur.

Puis-je récupérer le reflog depuis un nouveau clone ?

Non : consultez le dépôt où le rebase a eu lieu. Les entrées sont locales et peuvent expirer. Si le commit existe encore ailleurs, cherchez-le dans une autre copie ou une branche distante.

Dois-je remettre toute la branche en arrière pour un seul commit ?

Non. Une fois l’ancien historique protégé, vous pouvez examiner le commit et envisager un git cherry-pick sur une branche de travail propre. Vérifiez d’abord qu’il n’a pas déjà été rejoué sous un autre identifiant.

Les guides officiels à garder sous la main

Cette astuce t'a aidé ? ça a marché ?

#git #rebase #reflog

écrit par larevuegeek LaRevueGeek décrypte l'actualité high-tech et la culture geek depuis 2014 : tests, bons plans, ciné et tout ce qui touche, de près ou de loin, au monde des geeks.

S'abonner · 33,2 k

$ ls ./a-lire-aussi