撤消git rebase的最简单，快速和万无一失的方法是什么？

Question

我是Git变形的新手，希望能够完全轻松地恢复变形。我找到了涉及多个步骤并使用git reflog等高级命令的解决方案。我担心我不能正确地应用这些和/或需要花费大量时间来弄清楚到底要做什么。

是否有一个简单，快速和万无一失的解决方案，即使它是愚蠢的＆＃34;

我自己＆＃34;哑巴＆＃34;解决方案：在文件系统级别复制项目文件夹，然后在＆＃34;失败后＃34; rebase只删除原始文件夹并将备份重命名为原始名称。

Answer 1

引用“ORIG_HEAD”存储先前的HEAD提交，并将撤消rebase或合并。

git reset --hard ORIG_HEAD

来自文档：

  

ORIG_HEAD是由以强烈方式移动HEAD的命令创建的，用于在操作之前记录HEAD的位置，以便您可以轻松地将分支的尖端更改回运行之前的状态

文档表明它是为此特定目的而设计的。

Answer 2

在进行rebase之前将当前的工作推送到你的git服务器（github等）。

然后你可以安全地重新定义，如果你想恢复，你可以删除该文件夹并从服务器克隆它。或重置为上游头。

Answer 3

只要这是纯粹的本地化，也就是说，您不会在重新定位和可能还原之间推动您的分支，只需在您进行重新定位的同一提交中创建一个额外的备份分支即可。然后该分支将保持不变，如果出现问题，您可以重置为该分支。并且备份分支将保持不变，直到您专门删除它为止。

使用以下命令创建备份分支：

git branch backup 

然后做rebase：

git rebase <branch-to-rebase-on>

如果你想在rebase完成后恢复，只需执行：

git reset --hard backup

这会将当前分支重置为与备份相同的提交，这是您在rebase之前开始的地方。请注意，所有更改或新提交都将被丢弃！

如果您在rebase期间发现（例如在修复冲突时），您想要取消rebase，您可以随时执行：

git rebase --abort

Answer 4

如果您确实使用ORIG_HEAD重设和取消了变基，请确保使用Git 2.22（2019年第二季度）

  在C中重新实现的

“ git rebase”未正确设置ORIG_HEAD，该问题已得到纠正。

请参见commit cbd29ea的commit c2d9629，commit eaf8160，commit e6aac81，Johannes Schindelin (dscho)（2019年3月3日）。
^{（由Junio C Hamano -- gitster --在commit 9fbcc3d中合并，2019年3月20日）}

  

内置rebase：在重新设置基准之前仅设置一次ORIG_HEAD

     

从技术上讲，脚本版本仅在两个位置设置ORIG_HEAD（   确实可以是一个，因为它叫git checkout $onto^0   在两种情况下都启动重新基准以及是否需要捷径   它称为git update-ref $orig_head）。

     

实际上，每ORIG_HEAD 隐式重置git reset --hard   被叫。

     

但是，我们真正想要的是在   重新开始。

     

所以我们做吧。

     

内置rebase：无需两次检出onto

     

在将基准归结为快速转发的情况下，内置   重新设置工作树两次的基准：

     

  
• 一旦在onto开始变基，
  然后，
• 意识到原来的（变基前）HEAD是祖先，   我们基本上已经快进了rebase后的HEAD，   调用reset_head()来更新原始参考并指向HEAD   回到它。
  

     

第二个reset_head()调用不需要触摸工作树，   但是，因为它不会更改实际的提示提交（因此   无论如何，工作树都应保持不变）：只需将ref   已更新（因为变基已分离了HEAD，而我们想返回到   重新建立基础的分支）。