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

Question

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

是否有一个简单，快速和万无一失的解决方案，即使它是“愚蠢的”？

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

Answer 1

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

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重置和取消rebase，请确保使用Git 2.22（2019年第2季度）

在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：在rebase之前设置ORIG_HEAD一次

从技术上讲，脚本版本只在两个位置设置ORIG_HEAD（实际上可能是一个，因为它调用git checkout $onto^0来启动rebase，如果它可以采用捷径，并且在两种情况下都称为git update-ref $orig_head）。

实际上，每当调用ORIG_HEAD时，它都会隐式重置git reset --hard。

但是，我们真正想要的是它在rebase的开头只设置了一次。

所以，让我们这样做。

内置rebase：无需两次检查onto

在rebase归结为快进的情况下，内置的rebase重置工作树两次：

• 曾经在onto开始变革，
• 然后我意识到原来的（预先变形）HEAD是一个祖先，我们基本上已经快速转发到后基础HEAD，reset_head()被召唤来更新原始参考并将HEAD指向它。

第二个reset_head()调用不需要触及工作树，因为它不会改变实际的提示提交（因此工作树应该保持不变）：只需要更新ref（因为rebase分离了HEAD） ，我们想回到开始使用rebase的分支。