git 无法解决变基冲突

Can't resolve rebase conflict

提问by Roman Newaza

foo:/opt/bar$ git status
# On branch develop
nothing to commit (working directory clean)

foo:/opt/bar$ git pull --rebase origin develop
From ssh://xxx/yyy
* branch develop -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: Subscription logging added.
Using index info to reconstruct a base tree...
<stdin>:120: trailing whitespace.
* @return integer
<stdin>:143: trailing whitespace.
* @return integer
<stdin>:166: trailing whitespace.
* @return integer
<stdin>:189: trailing whitespace.
* @return integer
<stdin>:212: trailing whitespace.
* @return integer
warning: squelched 3 whitespace errors
warning: 8 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging app/config/config.yml
CONFLICT (content): Merge conflict in app/config/config.yml
Failed to merge in the changes.
Patch failed at 0001 Subscription logging added.

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".

foo:/opt/bar$ git status
# Not currently on any branch.
# Unmerged paths:
# (use "git reset HEAD <file>..." to unstage)
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: app/config/config.yml
#
no changes added to commit (use "git add" and/or "git commit -a")

foo:/opt/bar$ git add -A

foo:/opt/bar$ git status
# Not currently on any branch.
nothing to commit (working directory clean)

foo:/opt/bar$ git rebase --continue
Applying: Subscription logging added.
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".

foo:/opt/bar$ git add -A

foo:/opt/bar$ git status
# Not currently on any branch.
nothing to commit (working directory clean)

foo:/opt/bar$ git rebase --continue
Applying: Subscription logging added.
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".

foo:/opt/bar$

回答by Haralan Dobrev

You are on the right path. You just need to use skip the commit on which you have problems:

你走在正确的道路上。你只需要使用跳过你有问题的提交：

git rebase --skip

You have fixed the conflict, but this has resulted in no changes compared to the previous commit. In this case you cannot just git rebase --continue, because you are telling Git to create an empty commit, which is not allowed.

您已经修复了冲突，但与之前的提交相比，这并没有导致任何更改。在这种情况下，您不能只是git rebase --continue，因为您告诉 Git 创建一个空提交，这是不允许的。

If you have conflicts for any other commits you should still use git rebase --continue.

如果您有任何其他提交的冲突，您仍然应该使用git rebase --continue.

The --skipoption is also useful when you don't want to include certain commit at all in the newly produced history.

--skip当您根本不想在新生成的历史记录中包含某些提交时，该选项也很有用。

回答by VonC

git rebase --skipis indeed the right solution, except there is a case where it would get stuck and wouldn't be able to go on with the current rebase.

git rebase --skip确实是正确的解决方案，除非有一种情况会卡住并且无法继续使用当前的 rebase。

Git 2.0.2 (July 2014) has fixed that bug: see commit 95104c7by brian m. carlson (bk2204):

Git的2.0.2（2014年7月）已经修正了错误：看到提交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 文件的值保持不变。