如何轻松撤消git重基？冗长的手动方法是：
签出两个分支的提交父级创建并签出临时分支手工挑选所有提交重置故障的重基分支以指向临时分支
在我目前的情况下，这是可行的，因为我可以很容易地发现两个分支的提交（一个是我的东西，另一个是同事的东西）。然而，我的方法给我的印象是次优且容易出错（假设我刚刚用自己的两个分支重新建立了基础）。
澄清：我所说的是一个重基，在重基过程中，多次提交被重复，而不仅仅是一次。
当前回答
使用reflog对我不起作用。
对我有用的东西与这里描述的相似。在.git/logs/refs中打开以重新基于分支命名的文件，找到包含“rebase finsihed”的行，类似于：
5fce6b51 88552c8f Kris Leech <me@example.com> 1329744625 +0000 rebase finished: refs/heads/integrate onto 9e460878
签出行中列出的第二个提交。
git checkout 88552c8f
一旦确认这包含了我丢失的变化，我就分支起来，松了一口气。
git log
git checkout -b lost_changes
其他回答
如果您在分支机构，可以使用：
git reset --hard @{1}
HEAD不仅有一个引用日志（通过git reflog获得），每个分支也有reflog（通过gitreflog＜branch＞获得）。所以，如果您在master上，那么git-relog master将列出该分支的所有更改。您可以通过master@｛1｝、master@{2｝等引用这些更改。
gitrebase通常会多次更改HEAD，但当前分支只会更新一次。
@{1} 只是当前分支的快捷方式，因此如果您在master上，它等于master@{1}。
git reset——如果在交互式重基过程中使用git rese，硬ORIG_HEAD将无法工作。
假设我将master重新设置为我的功能分支，我得到了30个新的提交，这些提交会破坏一些东西。我发现通常只删除错误的提交是最简单的。
git rebase -i HEAD~31
最后31次提交的交互式重新基准（如果您选择太多，这不会有什么影响）。
只需将要删除的提交标记为“d”而不是“pick”即可。现在，提交被删除，从而有效地取消了重新基化（如果只删除重新基化时刚获得的提交）。
如果您成功地重新基于远程分支，并且不能git rebase--abort，那么您仍然可以使用一些技巧来保存您的工作，并且不需要强制推送。假设您的当前分支因错误而被重新设置为分支，并正在跟踪源/分支
gitbranch-m your branch rebased#重命名当前分支git checkout origin/your branch#签出到源已知的最新状态git结帐-b您的分行检查git-log您的分支，将其与git-log分支进行比较，并定义分支中缺少的提交gitcherry-pickCOMMIT_HASH用于分支中的每个提交推动您的更改。请注意，两个本地分支与远程/您的分支关联，您应该只推送您的分支
查尔斯的答案有效，但你可能想这样做：
git rebase --abort
重置后进行清理。
否则，您可能会收到消息“Interactive rebase already started”。
如果您在git rebase中搞乱了一些东西，例如git rebase--abort，而您有未提交的文件，它们将丢失，git reflog将不会有帮助。这件事发生在我身上，你需要跳出框框来思考。如果你像我一样幸运，并使用IntelliJ Webstorm，那么你可以右键单击->本地历史记录，并可以恢复到文件/文件夹的先前状态，无论你在版本控制软件中犯了什么错误。再运行一次故障保护总是很好的。
