Annulation d'un rebase git

Comment puis-je facilement annuler une modification de git?

Mes idées actuelles ne sont que des approches manuelles:

1. git checkout sur le parent de validation sur les deux branches
2. Créez une branche temporaire à partir de là
3. git cherry-pick tout s'engage à la main
4. remplacer la branche dans laquelle j'ai rebasé par la branche créée manuellement

Dans ma situation actuelle, cela fonctionnerait parce que je peux facilement repérer les commits des deux branches (l'une était mon affaire, l'autre était celle de mon collègue).

Cependant, mon approche me semble sous-optimale et sujette aux erreurs (disons que je venais de rebaser avec 2 de mes propres branches).

Clarification : je parle d'un rebase pendant lequel un tas de commits ont été rejoués. Non seulement un.

Le moyen le plus simple serait de trouver le commit principal de la branche tel qu'il était juste avant le rebase dans le reflog ...

git reflog

et de réinitialiser la branche actuelle (avec les mises en garde habituelles d'être absolument sûr avant de réinitialiser avec l' --hardoption).

Supposons que l'ancien commit était HEAD@{5}dans le journal de référence:

git reset --hard HEAD@{5}

Sous Windows, vous devrez peut-être citer la référence:

git reset --hard "HEAD@{5}"

Vous pouvez vérifier l'historique de l'ancienne tête du candidat en faisant simplement un git log HEAD@{5}( Windows:) git log "HEAD@{5}" .

Si vous n'avez pas désactivé les reflogs par branche, vous devriez pouvoir le faire simplement git reflog branchname@{1}car un rebase détache la tête de branche avant de se reconnecter à la tête finale. Je revérifierais ceci, bien que je ne l'ai pas vérifié récemment.

Par défaut, tous les reflogs sont activés pour les référentiels non nus:

[core]
    logAllRefUpdates = true

En fait, rebase enregistre votre point de départ ORIG_HEAD, c'est donc généralement aussi simple que:

git reset --hard ORIG_HEAD

Cependant, le reset, rebaseet mergetous enregistrent votre HEADpointeur d' origine dans ORIG_HEADainsi, si vous avez exécuté l'une de ces commandes depuis le rebase que vous essayez d'annuler, vous devrez utiliser le reflog.

La réponse de Charles fonctionne, mais vous voudrez peut-être faire ceci:

git rebase --abort

nettoyer après le reset.

Sinon, vous pouvez obtenir le message « Interactive rebase already started».

La réinitialisation de la branche à l'objet de validation pendant de son ancienne astuce est bien sûr la meilleure solution, car elle restaure l'état précédent sans aucun effort. Mais si vous avez perdu ces validations (par exemple, parce que vous avez récupéré votre référentiel entre-temps, ou s'il s'agit d'un nouveau clone), vous pouvez toujours rebaser la branche à nouveau. La clé est le --ontocommutateur.

Supposons que vous ayez une branche de sujet appelée avec imagination topic, que vous avez bifurquée masterlorsque la pointe de la commande a masterété 0deadbeefvalidée. À un moment donné pendant que topicvous étiez sur la branche, vous l'avez fait git rebase master. Vous voulez maintenant annuler cela. Voici comment:

git rebase --onto 0deadbeef master topic

Cela prendra toutes les validations topicqui ne sont pas masteractivées et les rejouera par dessus 0deadbeef.

Avec --onto, vous pouvez réorganiser votre histoire dans à peu près n'importe quelle forme .

S'amuser. :-)

En fait, j'ai mis une balise de sauvegarde sur la branche avant de faire une opération non triviale (la plupart des rebases sont triviales, mais je le ferais si cela semble complexe).

Ensuite, la restauration est aussi simple que git reset --hard BACKUP.

Dans le cas où vous aviez poussé votre branche vers un référentiel distant (généralement son origine) et que vous avez ensuite effectué un rebase réussi (sans fusion) ( git rebase --abortdonne "Pas de rebase en cours"), vous pouvez facilement réinitialiser la branche en utilisant la commande:

git reset --hard origin / {branchName}

Exemple:

$ ~/work/projects/{ProjectName} $ git status
On branch {branchName}
Your branch is ahead of 'origin/{branchName}' by 135 commits.
  (use "git push" to publish your local commits)

nothing to commit, working directory clean

$ ~/work/projects/{ProjectName} $ git reset --hard origin/{branchName}
HEAD is now at 6df5719 "Commit message".

$ ~/work/projects/{ProjectName} $ git status
On branch {branchName}
Your branch is up-to-date with 'origin/{branchName}.

nothing to commit, working directory clean

L'utilisation reflogn'a pas fonctionné pour moi.

Ce qui a fonctionné pour moi était similaire à celui décrit ici . Ouvrez le fichier dans .git / logs / refs nommé d'après la branche qui a été rebasée et recherchez la ligne qui contient "rebase finsihed", quelque chose comme:

5fce6b51 88552c8f Kris Leech <me@example.com> 1329744625 +0000  rebase finished: refs/heads/integrate onto 9e460878

Extraire le deuxième commit répertorié sur la ligne.

git checkout 88552c8f

Une fois confirmé, cela contenait mes changements perdus, je me suis ramifié et j'ai poussé un soupir de soulagement.

git log
git checkout -b lost_changes

Pour plusieurs validations, n'oubliez pas que toute validation fait référence à tout l'historique menant à cette validation. Ainsi, dans la réponse de Charles, lisez «l'ancien commit» comme «le plus récent des anciens commits». Si vous réinitialisez ce commit, tout l'historique menant à ce commit réapparaîtra. Cela devrait faire ce que vous voulez.

Suite à la solution de @Allan et @Zearin, je souhaite simplement pouvoir faire un commentaire mais je n'ai pas assez de réputation, j'ai donc utilisé la commande suivante:

Au lieu de faire git rebase -i --abort (notez le -i ), je devais simplement le faire git rebase --abort( sans le -i ).

En utilisant les deux -iet --aborten même temps, Git me montre une liste d'utilisation / d'options.

Mon statut de branche précédent et actuel avec cette solution est donc:

matbhz@myPc /my/project/environment (branch-123|REBASE-i)
$ git rebase --abort

matbhz@myPc /my/project/environment (branch-123)
$

Si vous avez réussi à rebaser contre une branche distante et que git rebase --abortvous ne pouvez pas, vous pouvez toujours faire quelques astuces pour enregistrer votre travail et ne pas avoir de push forcé. Supposons que votre branche actuelle qui a été rebasée par erreur soit appelée your-branchet effectue le suiviorigin/your-branch

• git branch -m your-branch-rebased # renommer la branche actuelle
• git checkout origin/your-branch # paiement vers le dernier état connu d'origine
• git checkout -b your-branch
• vérifier git log your-branch-rebased, comparer git log your-branchet définir les commits manquants dansyour-branch
• git cherry-pick COMMIT_HASH pour chaque commit your-branch-rebased
• pousser vos changements. Veuillez noter que deux succursales locales sont associées remote/your-branchet que vous ne devez pousseryour-branch

Disons que je rebase master dans ma branche de fonctionnalité et que je reçois 30 nouveaux commits qui cassent quelque chose. J'ai constaté que, souvent, il est plus facile de simplement supprimer les mauvais commits.

git rebase -i HEAD~31

Rebase interactive pour les 31 derniers commits (cela ne fait pas de mal si vous en choisissez beaucoup trop).

Prenez simplement les commits dont vous voulez vous débarrasser et marquez-les avec "d" au lieu de "choisir". Désormais, les validations sont supprimées, ce qui annule la réinitialisation (si vous supprimez uniquement les validations que vous venez d'obtenir lors de la réinitialisation).

Pour les débutants / ceux qui ont trop peur de faire une réinitialisation matérielle, vous pouvez extraire le commit du reflog, puis l'enregistrer en tant que nouvelle branche.

git reflog

Trouvez le commit juste avant de commencer le rebasage. Vous devrez peut-être faire défiler plus bas pour le trouver (appuyez sur Entrée ou PageDown). Prenez note du numéro HEAD et remplacez 57:

git checkout HEAD@{57}

Passez en revue la branche / commits, si cela semble bon, créez une nouvelle branche en utilisant cette HEAD:

git checkout -b new_branch_name

Si vous êtes sur une succursale, vous pouvez utiliser:

git reset --hard @{1}

Il n'y a pas seulement un journal de référence pour HEAD (obtenu par git reflog), il existe également des reflogs pour chaque branche (obtenu par git reflog <branch>). Donc, si vous êtes masteractivé git reflog master, la liste de toutes les modifications apportées à cette branche sera répertoriée. Vous pouvez consulter que les changements par master@{1}, master@{2}, etc.

git rebase changera généralement HEAD plusieurs fois mais la branche actuelle ne sera mise à jour qu'une seule fois.

@{1}est simplement un raccourci pour la branche en cours , il est donc égal à master@{1}si vous êtes activé master.

git reset --hard ORIG_HEADne fonctionnera pas si vous l'avez utilisé git resetlors d'une interaction rebase.

Ce que je fais d'habitude c'est git reset #commit_hash

au dernier commit où je pense que le rebase n'a eu aucun effet.

puis git pull

Maintenant, votre branche doit correspondre exactement comme maître et les validations rebasées ne doivent pas y être.

Maintenant, on peut juste choisir les commits sur cette branche.

J'ai essayé toutes les suggestions avec reset et reflog sans succès. La restauration de l'historique local d'IntelliJ a résolu le problème des fichiers perdus

git reset --hard origin / {branchName}

est la bonne solution pour réinitialiser toutes vos modifications locales effectuées par rebase.

Si vous gâchez quelque chose dans un rebase git, par exemple git rebase --abort, pendant que vous avez des fichiers non validés , ils seront perdus et git reflogne vous aideront pas. Cela m'est arrivé et vous devrez sortir des sentiers battus ici. Si vous avez de la chance comme moi et que vous utilisez IntelliJ Webstorm, vous pouvez right-click->local historyet pouvez revenir à un état précédent de vos fichiers / dossiers, quelles que soient les erreurs que vous avez faites avec le logiciel de version. Il est toujours bon d'avoir une autre sécurité intégrée en cours d'exécution.