Git rebase 合并冲突无法继续

Git rebase merge conflict cannot continue

提问by awm

I'm trying to rebase 'dev' to catch up to 'master' branch.

我正在尝试重新设置“dev”以赶上“master”分支。

$ git checkout dev 
$ git rebase master 
First, rewinding head to replay your work on top of it...
Applying: Corrected compilation problems that came from conversion from SVN.
Using index info to reconstruct a base tree...
M       src/com/....
<stdin>:125: trailing whitespace.
/**
<stdin>:126: trailing whitespace.
 *
<stdin>:127: trailing whitespace.
 */
<stdin>:128: trailing whitespace.
package com....
<stdin>:129: trailing whitespace.

warning: squelched 117 whitespace errors
warning: 122 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging src/com/....
CONFLICT (content): Merge conflict in src/com/...
Failed to merge in the changes.
Patch failed at 0001 Corrected compilation problems that came from conversion from SVN.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".

$ vi src/com/.....   { fixed the merge issue on one file } 
$ git add -A . 
$ git rebase --continue 
src/com/....: needs merge
You must edit all merge conflicts and then
mark them as resolved using git add
$ vi src/com....      { verified, no >>> or <<< left, no merge markers } 
$ git rebase --continue 
Applying: Corrected compilation problems that came from conversion from SVN.
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".

Any ideas?

有任何想法吗？

回答by Chris Nicola

There are a couple situations where I've seen rebaseget stuck. One is if the changes become null (a commit has changes that were already made previously in the rebase) in which case you may have to use git rebase --skip.

我见过有几种情况rebase会卡住。一种是如果更改为空（提交具有先前在变基中已经进行的更改），在这种情况下您可能必须使用git rebase --skip.

It's pretty easy to tell. If you do git statusit should show no changes. If so just skip it. If that isn't the case please post a copy of git statusand I can try to help further.

这很容易说出来。如果你这样做，git status它应该不会显示任何变化。如果是这样就跳过它。如果不是这种情况，请发布一份副本，git status我可以尝试进一步提供帮助。

回答by Steve Reed

One of the times that I have run into this issue is when doing a git commitafter a git add. So, the following sequence will produce the rebase error you mention:

我遇到这个问题的时候之一是git commit在git add. 因此，以下序列将产生您提到的变基错误：

git add <file with conflict>
git commit -m "<some message>"
git rebase --continue

git add <file with conflict>
git commit -m "<some message>"
git rebase --continue

While, the sequence below runs without any errors, and continues the rebase:
git add <file with conflict>
git rebase --continue

同时，下面的序列运行没有任何错误，并继续变基：
git add <file with conflict>
git rebase --continue

It might be possible that git add -Awith the "All" option is creating a similar situation. (Please note, I am very inexperienced in git, so this answer may not be correct.) To be safe, the git rebase --skipseems to also work well in this situation.

git add -A使用“全部”选项可能会造成类似的情况。（请注意，我对 git 非常缺乏经验，所以这个答案可能不正确。）为了安全起见，git rebase --skip似乎在这种情况下也能很好地工作。

回答by VonC

Note: Git 2.0.2 (July 2014) has fixed one case where a git rebase --skipwould get stuck and wouldn't be able to go on with the current rebase.
See commit 95104c7by brian m. carlson (bk2204)

注意：Git 2.0.2（2014 年 7 月）修复了一种情况，即 agit rebase --skip会卡住并且无法继续使用当前的 rebase。
见提交95104c7由布赖恩·米 卡尔森 ( bk2204)

rebase--merge: fix --skipwith two conflicts in a row

rebase--merge：修复--skip连续两个冲突

If git rebase --mergeencountered a conflict, --skipwould not work if the next commit also conflicted.
The msgnumfile would never be updated with the new patch number, so no patch would actually be skipped, resulting in an inescapable loop.

Update the msgnumfile's value as the first thing in call_merge.
This also avoids an "Already applied" message when skipping a commit.
There is no visible change for the other contexts in which call_merge is invoked, as the msgnum file's value remains unchanged in those situations.

如果git rebase --merge遇到冲突，--skip如果下一次提交也发生冲突，则不会起作用。
该msgnum文件永远不会用新的补丁号更新，因此实际上不会跳过任何补丁，从而导致不可避免的循环。

更新msgnum文件的值作为 call_merge 中的第一件事。
这也避免了Already applied跳过提交时出现“ ”消息。
调用 call_merge 的其他上下文没有明显变化，因为在这些情况下 msgnum 文件的值保持不变。

回答by John Brodie

$ vi src/com....      { verified, no >>> or <<< left, no merge markers } 
$ git rebase --continue 

Looks like you forgot to git addyour changes...

看起来你忘记了git add你的改变......