有3个提交 - 一个正确，然后两个愚蠢的清理，错别字等。所以我想要压扁它们。消防：
git rebase -i HEAD~3
听起来很简单，它应该可行 - 我在遇到问题之后尝试过它，在一个全新的回购中，它按预期工作。编辑显示3个提交，选择顶部，挤压另外两个，保存并退出，完成。如果我在详细模式下运行，我会看到更多细节 - git通过检查我选择的第一个提交进入分离的HEAD状态，然后执行'Rebasing 2/3'和'Rebasing 3/3'，显然创建了一些临时提交一路走来 - 然后成功的消息;编辑器在某些时候再次弹出，让我改变提交消息。一切都很好。
但同样的命令在工作回购中死亡！ 3在一个编辑器中提交，选择南瓜壁球......但是这一次，我没有看到'Rebasing 2/3'，而是'HEAD现在在my-SHA-1'之后的第一行，它遇到了一个致命的！
HEAD is now at 48a6c3d... <commit message>
fatal: ref HEAD is not a symbolic ref
但为什么会 git期望HEAD成为一个符号引用？ Rebase进程确实分离了HEAD - 就像我在探索性示例中看到的那样 - 那么为什么然后在第二个例子中致命，而不是在第一个例子中呢？ cat .git / HEAD给我提供了我选择的提交的SHA1 ......
我花了几个小时阅读和研究，但有些东西不在这里，我找不到它是什么！我怀疑可能某些钩子是负责任的（对它们知之甚少，并且知道有问题的仓库确实有一些）。感谢您的回答！
答案 0 :(得分：3)
也有可能执行git commit而不是git rebase --skip或git rebase --continue
这可能已经添加了不需要的提交。
您可以运行git reset HEAD~1，然后执行git rebase --continue来解决问题
答案 1 :(得分：1)
你的“工作”回购可能会以某种方式破坏。有关详细信息，请参阅I can't git rebase --interactive anymore。
我会尝试在你的工作回购中运行git status来弄清楚发生了什么。然后例如<{1}}，git rebase --abort或类似的东西可能是必需的。
我也会运行git merge --abort。
在您的repo和工作目录很好之后，交互式rebase应该可以正常工作。另请注意，如果您想触摸回购邮件中的第一个提交，则可能需要git fsck。