我正在将几个提交的分支重新定位到上游分支。我被某种故障阻止了,我无法继续我的分支中的剩余提交,所以我需要一种方法来在 git reset 似乎不起作用时继续。
正如我所说的,我正在对一个分支进行 rebase 。我一直都这样 rebase ,我对一两个提交的冲突解决为空提交并不感到惊讶。但是在我完成冲突解决步骤(编辑冲突的文件并添加结果文件)之前,我不知道哪些提交。所以这是发生的事情的抽象版本:
$ git checkout working_branch
$ git rebase -i upstream
[Here it is reported that file.c has conflicts. I edit it.
The resulting diff is empty.]
$ git add file.c
$ git rebase --continue
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:
git commit --allow-empty
Otherwise, please use 'git reset'
rebase in progress; onto xxxsha
但是此时 git reset
没有帮助,我最终得到了相同的确切状态。我不希望有一个空的提交。我之前曾遇到过此过程中潜在的空提交,我一直很高兴让提交消失。
我想到了这个问题 git cherry-pick not working其中发生了几乎完全相同的结果,但是来自 cherry-picking 一个提交,而不是 rebase 一个分支。另一个询问者很高兴继续前进,而不是 cherry-pick 。逐步我猜 rebase 对每个提交都使用 cherry-pick,我有几个提交要逐步完成。在我的例子中,这发生在我的分支的第一次提交上,我需要一个真正的解决方案才能继续。
最佳答案
Gist 是仔细查看摘要行。答案是 git rebase --continue
如果您注意到它说无法应用的提交的摘要行实际上是下一次提交。我被屏幕上的文本与命令经常显示的通常的空提交消息的相似程度所困扰。但这是一种不同的信息。它实际上一直在继续,并且正在处理下一个提交,该提交被自动解析为空。文本包括分支下一次提交的摘要行,而不是我刚刚解决的提交的摘要行。因此,当以这种方式出现空提交状态时,可以不用多说,再次继续。
关于git - 当 Git rebase --continue 真的被空提交阻塞时如何继续,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45513613/