我正在处理一个变基列表并做了git add，进行了更改，然后是rebase --continue。
然而，在此期间我不小心输入了rebase --abort.
我想继续做我不小心中止的变基，所以我做了
git reflog
然后
git reset --hard HEAD@{2}
问题是如果我输入 git rebase --continue 它说我没有 rebase 正在进行中并且我
have 1 and 10 different commits each, respectively (use "git pull" to merge the remote branch into yours)
无论如何我可以回去继续变基还是我需要从分支中拉出并重做？
【问题讨论】：
首先要做的事情：你确实不想在这一点上做一个 git pull。即使你恢复了，你也可以恢复，但这会让你走错方向[1]。
因此，您遵循的步骤正确地恢复了在上一次 rebase 尝试期间提交的更改 - 这可能很有用。
但这与将 git 重新置于变基状态不同。还有其他事情正在发生 - 例如。 git 正在管理代表原始提交的补丁的待办事项列表。
据我所知，实际上没有办法重新启动已中止的变基。但是你可以使用rebase --onto 来近似它。
(a) 从旧变基的尖端（您已重置的位置）创建一个标签
(b) 重置回分支在变基之前的位置。 （您可以再次在 reflog 中找到它；这是 rebase --abort 发送给您的地方。）
(c) 现在，假设你有
x -- A -- B -- C -- D <--(branch)
\
x -- x -- o <--(master)
\
A' -- B' <-rebase_tag
其中rebase_tag是你在旧rebase尝试的尖端创建的标签，所以A'是A的重写，B'是B的重写，你仍然需要重写C 和 D。
您要做的是将C 和D 重写为B'。所以
git rebase --onto rebase_tag branch~2 branch
在这里，branch~2 可以替换为解析为 B 的任何表达式（在上次 rebase 尝试中重写的最后一个原始提交）。
当然，如果与原始 rebase 尝试相关的工作很少 - 如果它不需要太多时间并且没有很多复杂的合并解决方案正在进行 - 你可以只是从头开始。即使这样做，您也可以在解决冲突时使用“旧的重写提交”作为参考。
但假设您清楚如何计算--onto 参数的表达式，以上可能是“重新启动”rebase 的最简单方法。
[1] 这里要理解的是，某些 git 命令给出了非常详细/具体的建议；但是该建议是针对常见用例而编写的，在这些用例中，您已经完成了他们认为新用户通常会做的某些事情。你做不符合这些假设的事情很好，但他们假设任何人知道的足够多，不需要具体/详细的建议。
所以发生的事情是，你做了超出这些假设的事情，所以pull 建议不适用；如果您遵循它，您将朝着错误的方向前进。并不是说你仍然无法恢复——你可以——但它会更令人困惑。
【讨论】：