Est-ce que quelqu’un sait comment annuler facilement un rebit de git?
Le seul moyen qui vous vient à l’esprit est de le faire manuellement:
Dans ma situation actuelle, cela va marcher parce que je peux facilement repérer les commits des deux twigs (l’un était mes affaires, l’autre était les affaires de mon collègue).
Cependant, mon approche me semble sous-optimale et sujette à erreur (disons que je venais de rebaser avec deux de mes propres twigs).
Des idées?
Clarification: je parle d’une rebase au cours de laquelle un tas de commits ont été rejoués. Non seulement un.
Le moyen le plus simple serait de trouver le commit principal de la twig tel qu’il était immédiatement avant que la rebase ne démarre dans le reflog …
git reflog et pour réinitialiser la twig actuelle (avec les réserves habituelles sur la nécessité d’être absolument sûr avant de réinitialiser avec l’option --hard ).
Supposons que l’ancien commit était HEAD@{5} dans le journal de référence:
git reset --hard HEAD@{5}
Dans Windows, vous devrez peut-être citer la référence:
git reset --hard "HEAD@{5}"
Vous pouvez vérifier l’historique de l’ancien candidat en faisant simplement un git log HEAD@{5} ( Windows: git log "HEAD@{5}" ).
Si vous n’avez pas désactivé les refoulements par twig, vous devriez pouvoir faire simplement git reflog branchname@{1} car une rebase détache la twig avant de se reconnecter à la tête finale. Je vérifierais cela deux fois, mais comme 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 sharepoint départ dans ORIG_HEAD , ce qui est généralement aussi simple que:
git reset --hard ORIG_HEAD
Cependant, la reset , le rebase et la merge enregistrent tous votre pointeur HEAD origine dans ORIG_HEAD donc si vous avez effectué l’une de ces commandes depuis la réinitialisation 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
pour nettoyer après la reset .
Sinon, vous pouvez recevoir le message ” Interactive rebase already started “.
Réinitialiser la twig à l’object de validation en suspens de son ancienne astuce est bien sûr la meilleure solution, car elle restaure l’état précédent sans déployer d’effort. Mais si vous avez perdu ces commits (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 réorganiser la twig. La clé de ceci est le commutateur --onto .
Disons que vous aviez une twig de sujet appelée imaginativement topic , que vous avez divisée en master lorsque la pointe de master était le commit 0deadbeef . À un certain moment, alors que vous vous git rebase master sur la twig du topic , vous ne vous êtes pas git rebase master . Maintenant, vous voulez annuler cela. Voici comment:
git rebase --onto 0deadbeef master topic
Cela prendra tous les commits sur le topic qui ne sont pas sur le master et les rejouer sur 0deadbeef .
Avec --onto , vous pouvez réorganiser votre histoire en pratiquement n’importe quelle forme .
S’amuser. 🙂
Je mets en fait une balise de sauvegarde sur la twig avant toute opération non sortingviale (la plupart des rebases sont sortingviales, mais je le ferais si cela semble complexe).
Ensuite, la restauration est aussi simple que git reset --hard BACKUP .
Au cas où vous auriez poussé votre twig vers un repository distant (généralement son origine) et que vous avez effectué une rebase (sans fusion) ( git rebase --abort donne “Pas de rebase en cours”), vous pouvez facilement réinitialiser la twig 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
Au cas où vous n’auriez pas terminé le rebase et au milieu, les travaux suivants:
git rebase --abort
Utiliser le reflog n’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 twig qui a été rebasée et trouvez la ligne contenant “rebase finsihed”, quelque chose comme:
5fce6b51 88552c8f Kris Leech 1329744625 +0000 rebase finished: refs/heads/integrate onto 9e460878
Extraire le deuxième commit listé sur la ligne.
git checkout 88552c8f
Une fois confirmé, cela contenait mes changements perdus que je ramifiais et laissais échapper un soupir de soulagement.
git log git checkout -b lost_changes
Pour plusieurs validations, rappelez-vous que toute validation fait référence à tout l’historique menant à cette validation. Donc, dans la réponse de Charles, lisez “l’ancien commit” comme “le plus récent des anciens commits”. Si vous réinitialisez cette validation, alors tout l’historique précédant cette validation réapparaîtra. Cela devrait faire ce que vous voulez.
Suite à la solution de @Allan et @Zearin, j’aimerais pouvoir faire simplement 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 -i ) je devais simplement faire git rebase --abort ( sans le -i ).
L’utilisation --abort -i et --abort amène Git à afficher une liste d’utilisation / d’options.
Ainsi, mon statut de twig précédent et actuel avec cette solution est le suivant:
matbhz@myPc /my/project/environment (branch-123|REBASE-i) $ git rebase --abort matbhz@myPc /my/project/environment (branch-123) $
Je suis surpris que personne n’en ait déjà parlé ici. Rebase laisse l’ancien état sous la forme ORIG_HEAD , vous pouvez donc annuler la dernière rebase en exécutant:
git reset --hard ORIG_HEAD
Si vous avez réussi à effectuer un rebasage avec une twig distante et que vous ne pouvez pas git rebase --abort vous pouvez git rebase --abort même faire certaines astuces pour sauvegarder votre travail et ne pas avoir de git rebase --abort forcé. Supposons que votre twig actuelle qui a été rebasée par erreur s’appelle your-branch et suit l’ origin/your-branch
git branch -m your-branch-rebased # renomme la twig courante git checkout origin/your-branch # checkout au dernier état connu de l’origine git checkout -b your-branch git log your-branch-rebased , comparer à git log your-branch et définir les commits manquants dans your-branch git cherry-pick COMMIT_HASH pour chaque commit dans your-branch-rebased remote/your-branch et que vous ne devez pousser que your-branch Disons que je rebase le master sur ma twig de fonctionnalités et que je reçois 30 nouveaux commits qui cassent quelque chose. J’ai constaté que souvent, il est plus facile de supprimer les mauvais commits.
git rebase -i HEAD~31
Rebase interactif pour les 31 derniers commits (ça ne fait pas de mal si vous en choisissez trop).
Prenez simplement les commits dont vous voulez vous débarrasser et marquez-les avec “d” au lieu de “pick”. Maintenant, les validations sont supprimées, ce qui annule le rebase (si vous ne supprimez que les commits que vous venez d’obtenir lors du rebasage).
Si vous gâchez quelque chose dans une rebase git, par exemple, git rebase --abort , alors que vous avez des fichiers non git rebase --abort , ils seront perdus et git reflog ne vous aidera pas. Cela m’est arrivé et vous devrez sortir des sentiers battus. Si vous avez de la chance comme moi et que vous utilisez IntelliJ Webstorm, vous pouvez right-click->local history bouton right-click->local history et revenir à l’état précédent de vos fichiers / dossiers, quelles que soient les erreurs du logiciel de gestion des versions. Il est toujours bon d’avoir un autre système de sécurité en marche.
Pour annuler, vous pouvez entrer la commande suivante:
git -c core.quotepath=false rebase --abort