撤消 git rebase

对于多次提交，请记住任何提交都会引用导致该提交的所有历史记录。所以在查尔斯的回答中，将“旧提交”读作“最新的旧提交”。如果您重置为该提交，则导致该提交的所有历史记录都将重新出现。这应该做你想要的。

如果您成功地针对远程分支重新设置基础并且无法git rebase --abort，您仍然可以采取一些技巧来保存您的工作并且没有强制推送。假设您当前错误地重新建立基础的分支称为 your-branch 并正在跟踪 origin/your-branch

git branch -m your-branch-rebased # 重命名当前分支

git checkout origin/your-branch # checkout 到源已知的最新状态

git checkout -b 你的分支

检查 git log your-branch-rebased，与 git log your-branch 进行比较，并定义 your-branch 中缺少的提交

git cherry-pick COMMIT_HASH 为 your-branch-rebased 中的每个提交

推动你的改变。请注意，两个本地分支与 remote/your-branch 相关联，您应该只推送 your-branch

如果您不想进行硬重置...

您可以从 reflog 签出提交，然后将其保存为新分支：

git reflog

在你开始变基之前找到提交。您可能需要进一步向下滚动才能找到它（按 Enter 或 PageDown）。记下 HEAD 编号并替换 57：

git checkout HEAD@{57}

查看分支/提交，如果正确，则使用此 HEAD 创建一个新分支：

git checkout -b new_branch_name

按照@Allan 和@Zearin 的解决方案，我希望我可以简单地发表评论，但我没有足够的声誉，所以我使用了以下命令：

而不是做 git rebase -i --abort（注意 -i）我必须简单地做 git rebase --abort（没有 -i）。

同时使用 -i 和 --abort 会导致 Git 向我显示使用/选项列表。

所以我以前和当前使用此解决方案的分支状态是：

matbhz@myPc /my/project/environment (branch-123|REBASE-i)
$ git rebase --abort

matbhz@myPc /my/project/environment (branch-123)
$

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

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

git reflog

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

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

最后，您使用 git branch 命令。

git branch recover-branch e86a52b851e

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

假设我将 master 重新定位到我的功能分支，我得到了 30 个新的提交，这些提交破坏了一些东西。我发现通常最容易删除错误的提交。

git rebase -i HEAD~31

最后 31 次提交的交互式变基（如果你选择太多也没关系）。

只需获取您想要摆脱的提交并用“d”而不是“pick”标记它们。现在，提交被有效地删除，撤消了变基（如果您只删除了变基时刚刚获得的提交）。

如果您在分支上，您可以使用：

git reset --hard @{1}

不仅有 HEAD 的参考日志（由 git reflog 获得），还有每个分支的 reflogs（由 git reflog <branch> 获得）。因此，如果您在 master 上，那么 git reflog master 将列出对该分支的所有更改。您可以通过 master@git reflog、master@git reflog <branch> 等来引用该更改。

git rebase 通常会多次更改 HEAD，但当前分支只会更新一次。

@{1} 只是一个 shortcut for the current branch，因此如果您在 master 上，它等于 master@shortcut for the current branch。

如果您在交互式 rebase 中使用 git reset，git reset --hard ORIG_HEAD 将不起作用。

尽管事实上它应该是可自动化的（至少大部分情况下），但这些答案都不是完全自动的，这让我很恼火。我创建了一组别名来尝试解决这个问题：

# Useful commands
#################

# Undo the last rebase
undo-rebase = "! f() { : git reset ; PREV_COMMIT=`git x-rev-before-rebase` && git reset --merge \"$PREV_COMMIT\" \"$@\";}; f"

# See what changed since the last rebase
rdiff = "!f() { : git diff ; git diff `git x-rev-before-rebase` "$@";}; f"

# Helpers
########
# Get the revision before the last rebase started
x-rev-before-rebase = !git reflog --skip=1 -1 \"`git x-start-of-rebase`\" --format=\"%gD\"

# Get the revision that started the rebase
x-start-of-rebase = reflog --grep-reflog '^rebase (start)' -1 --format="%gD"

您应该能够对此进行调整以允许非常轻松地返回任意数量的变基（处理 args 是最棘手的部分），如果您快速连续地执行多个变基并在此过程中搞砸了一些事情，这将很有用。

注意事项

如果任何提交消息以“rebase (start)”开头，它会感到困惑（请不要这样做）。您可以通过为您的正则表达式匹配以下内容来使正则表达式更具弹性以改善情况：

--grep-reflog "^rebase (start): checkout " 

警告：未测试（正则表达式可能需要调整）

我没有这样做的原因是因为我不是 100% 的变基总是从结帐开始。谁能证实这一点？

[如果您对函数开头的 null (:) 命令感到好奇，这是为别名设置 bash 补全的一种方式]

我通常做的是git reset #commit_hash

到我认为 rebase 无效的最后一次提交。

然后git pull

现在，您的分支应该与 master 完全匹配，并且 rebased 提交不应该在其中。

现在可以只挑选这个分支上的提交。

我用 reset 和 reflog 尝试了所有建议，但没有成功。恢复 IntelliJ 本地历史解决了丢失文件的问题

如果你在 git rebase 中搞砸了一些东西，例如 git rebase --abort，当你有未提交的文件时，它们将会丢失并且 git reflog 将无济于事。这发生在我身上，你需要在这里跳出框框思考。如果您像我一样幸运并且使用 IntelliJ Webstorm，那么无论您在版本控制软件中犯了什么错误，您都可以 right-click->local history 并恢复到文件/文件夹的先前状态。运行另一个故障保护总是好的。