【问题标题】:How to proceed when Git rebase --continue is REALLY REALLY blocked by empty commit当 Git rebase --continue 真的被空提交阻止时如何继续
【发布时间】:2018-01-12 19:03:54
【问题描述】:

我将几个提交的分支重新定位到上游分支。我因某种故障而无法继续执行分支中的剩余提交,因此我需要一种方法来在 git reset 似乎不起作用时继续。

正如我所说,我正在重新定位一个分支。我一直都在做这样的变基,对于一两个提交的冲突最终解决为空提交,我并不感到惊讶。但在我完成冲突解决步骤(编辑冲突文件并添加结果文件)之前,我不知道哪些提交。所以这里是发生的事情的一个抽象版本:

$ 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 的问题,其中出现了几乎完全相同的结果,但来自于挑选一个提交,而不是重新设置分支。另一位询问者很高兴继续进行而不是挑选樱桃。逐步我猜 rebase 对每个提交都使用cherry-pick,我有几个提交要逐步完成。就我而言,这发生在我的分支的第一次提交时,我需要一个真正的解决方案才能继续。

【问题讨论】:

    标签: git rebase branching-and-merging


    【解决方案1】:

    要点是仔细查看摘要行。如果您注意到它说不能应用的提交的摘要行实际上是下一个提交,那么答案结果是git rebase --continue。我被屏幕上的文本与命令经常显示的通常空提交消息的相似程度吓坏了。但这是一种不同的信息。它实际上一直在继续,并且正在处理下一次提交,该提交被自动解析为空。文本包含来自分支的下一次提交的摘要行,而不是我刚刚解决的提交的摘要行。所以当以这种方式出现空提交状态时,可以直接再次继续。

    【讨论】:

      【解决方案2】:

      在你解决完冲突并发现你留下一个空提交后,你可以跳过它:

      $ git rebase --skip
      

      【讨论】:

      • 我相信这适用于通常情况,但不适用于困扰我的情况。
      • 只需键入 git rebase --continue 而不是 git rebase --skip 似乎更自然。我发现结果是一样的。
      猜你喜欢
      • 2017-09-25
      • 2017-11-04
      • 1970-01-01
      • 2022-10-07
      • 2015-03-26
      • 1970-01-01
      • 2020-06-28
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多