实际上，rebase将您的起点保存到ORIG_HEAD，因此这通常很简单：

git reset --hard ORIG_HEAD

然而，reset、rebase和merge都会将原始HEAD指针保存到ORIG_HEAD中，因此，如果您在尝试撤消rebase之后执行了这些命令，则必须使用reflog。

如果您在git rebase中搞乱了一些东西，例如git rebase--abort，而您有未提交的文件，它们将丢失，git reflog将不会有帮助。这件事发生在我身上，你需要跳出框框来思考。如果你像我一样幸运，并使用IntelliJ Webstorm，那么你可以右键单击->本地历史记录，并可以恢复到文件/文件夹的先前状态，无论你在版本控制软件中犯了什么错误。再运行一次故障保护总是很好的。

实际上，rebase将您的起点保存到ORIG_HEAD，因此这通常很简单：

git reset --hard ORIG_HEAD

然而，reset、rebase和merge都会将原始HEAD指针保存到ORIG_HEAD中，因此，如果您在尝试撤消rebase之后执行了这些命令，则必须使用reflog。

假设我将master重新设置为我的功能分支，我得到了30个新的提交，这些提交会破坏一些东西。我发现通常只删除错误的提交是最简单的。

git rebase -i HEAD~31

最后31次提交的交互式重新基准（如果您选择太多，这不会有什么影响）。

只需将要删除的提交标记为“d”而不是“pick”即可。现在，提交被删除，从而有效地取消了重新基化（如果只删除重新基化时刚获得的提交）。

另一种不需要进行硬重置的方法是创建一个具有您所需起点的新分支。

与其他解决方案一样，您可以使用reflog来找到正确的起点。

git reflog

（您也可以在此处使用git-log-g了解更多详细信息）

然后注意对提交SHA的引用（例如：e86a52b851e）。

最后，使用gitbranch命令。

git branch recover-branch e86a52b851e

参考：https://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery#_data_recovery

将分支重置为其旧提示的悬空提交对象当然是最好的解决方案，因为它可以恢复以前的状态，而无需花费任何精力。但是，如果您碰巧丢失了这些提交（例如，因为您同时垃圾收集了存储库，或者这是一个新的克隆），您可以再次重新设置分支的基础。这一点的关键是--on开关。

假设你有一个想象中的主题分支，称为topic，当master的提示是0deadbeef提交时，你分支了master。在主题分支的某个时刻，您完成了git rebase master。现在您要撤消此操作。以下是操作方法：

git rebase --onto 0deadbeef master topic

这将接收所有关于主题的提交，但这些提交不在主控上，并在0个标题的顶部回放它们。

有了--on，你可以将你的历史重新整理成任何形状。

玩得开心。：-）