13

有 3 个提交 - 一个是正确的，然后是两个愚蠢的清理，错别字等。所以我想压缩它们。开火：

git rebase -i HEAD~3

听起来很简单，它应该可以工作 - 我在遇到问题后尝试了它，在一个全新的 repo 中，它按预期工作。编辑器显示 3 个提交，选择顶部，挤压另外两个，保存并退出，完成。如果我在详细模式下运行，我会看到更多详细信息 - git 通过检查我“选择”的第一个提交进入分离 HEAD 状态，然后执行“重新设置 2/3”和“重新设置 3/3”，显然创建了一些临时提交一路走来——然后是成功信息；编辑器在某个时候再次弹出，让我更改提交消息。一切都好。

但是相同的命令在工作回购中死了！在编辑器中进行 3 次提交，pick-squash-squash .. 但是这一次，我没有看到“Rebasing 2/3”，而是在“HEAD 现在位于 my-SHA-1”之后的第一行，它遇到了致命的！

HEAD is now at 48a6c3d... <commit message>
fatal: ref HEAD is not a symbolic ref

但是为什么git 会期望 HEAD 是一个象征性的 ref 呢？Rebase 过程确实分离了 HEAD - 与我在探索性示例中看到的一样 - 那么为什么在第二个示例中是致命的，但在第一个示例中不是？cat .git/HEAD 给我我“选择”的提交的 SHA1 ......

我花了几个小时阅读和研究，但有些东西不在这里，我找不到它是什么！我怀疑可能有一些钩子是负责任的（对它们知之甚少，并且知道有问题的回购确实有一些）。感谢您考虑回答这个问题！

4

2 回答 2

6

您的“工作”回购可能以某种方式损坏。有关详细信息，请参阅I can't git rebase --interactive。

我会尝试git status在您的工作存储库中运行以找出发生了什么。然后例如git rebase --abort，git merge --abort或可能需要类似的东西。

我也会跑git fsck。

在您的 repo 和工作目录正常运行后，交互式 rebase 应该可以正常工作。另请注意，git rebase --root --preserve-merges ...如果您想触摸 repo 中的第一个提交，您可能需要。

于 2017-07-06T09:44:18.013 回答
3

也有可能git commit被执行而不是git rebase --skip或git rebase --continue

这可能添加了不需要的提交。

您可以运行git reset HEAD~1然后执行git rebase --continue以解决问题

于 2020-08-19T06:23:49.307 回答