Git rebase—即使所有合并冲突都已解决，仍然会继续报错

我正面临一个我不知道如何解决的问题。

我从我的分支对master做了一个rebase:

git rebase master

并得到以下错误

 First, rewinding head to replay your work on top of it...
Applying: checkstyled.
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging AssetsLoader.java
CONFLICT (content): Merge conflict in AssetsLoader.java
Failed to merge in the changes.
Patch failed at 0001 checkstyled.

所以我去我最喜欢的编辑器，修复了1行冲突，保存文件，并做了一个git状态，得到以下输出:

 # Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#  modified:   PassengerContactHandler.java
#
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#  both modified:      AssetsLoader.java
#

我做了一个git添加AssetsLoader.java和一个git状态，并得到如下:

 # Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#  modified:   AssetsLoader.java
#  modified:   PassengerContactHandler.java
#

当我git rebase -continue时，我得到:

git rebase --continue
You must edit all merge conflicts and then
mark them as resolved using git add

我知道我可以跳过补丁并继续重新建立基础，但我不确定passenger - contacthandler .java中的更改是否会重新建立到我的分支中。

所以我不确定，我该怎么做?

编辑:是否冲突解决后的文件与原始版本完全相同?

非常感谢， 卢卡斯< / p >

编辑，我又遇到了这样的事:

又发生在我身上了，

(307ac0d...)|REBASE)$ git status
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   assets/world/level1/Level-1.xml
#   modified:   George.java
#   modified:   DefaultPassenger.java
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   mb-art/originalAssets/27dec/

((307ac0d…)|REBASE)$ git REBASE—继续

You must edit all merge conflicts and then
mark them as resolved using git add

git -版本

git version 1.7.1
144977 次浏览
小开

您在assetloader .java中错过了合并冲突。打开它，寻找冲突标记(“>>>>”，“====”，“<<<<< <”)，然后再次执行git add。如果你很难找到它，就做一个“git diff - staging”。

小开

试着在你的命令行中运行:

$ git mergetool

应该会弹出一个交互式编辑器，允许您解决冲突。这比手动操作要简单，而且git在合并时也能识别。也将避免当您尝试手动操作时，意外发生的不完全合并的情况。

小开

我刚刚遇到了这个问题，虽然我认为可能有一些原因，但这是我的……

我有一个git预提交钩子，它在某些条件下拒绝提交。这在手动提交时很好，因为它将显示钩子的输出，我可以使用commit——no-verify修复它或选择忽略它。

问题似乎是，当重基时，rebase——continue也会调用钩子(为了提交最新一轮的更改)。但是rebase不会显示钩子输出，它只会看到它失败了，然后抛出一个不太具体的错误，说“你必须编辑所有合并冲突，然后将它们标记为使用git add解决”

要解决这个问题，请阶段性地执行所有更改，而不是执行“git rebase—continue”，而是尝试执行“git commit”。如果你也遇到了同样的问题，你应该看到它失败的原因。

有趣的是，虽然git rebase不显示来自git钩子的输出，但它确实接受——no-verify来绕过钩子。

小开

似乎是Git 1.7中的一个错误

这里有一篇关于如何解决这个问题的好文章。(链接在2022年似乎不再有效)

如果你做一个

git diff

在解决了你们的矛盾之后

git rebase --continue

应该工作。

小开

发生这种情况是因为在修复冲突时，您删除了应用于您所基于的分支的补丁中的所有代码。如果您确定已添加所有更改:使用git rebase --skip继续。

更多细节:

通常，当在重基期间修复冲突时，您将编辑冲突文件，保留当前应用于重基分支的补丁中的部分或全部代码。在修复补丁后做

git add your/conflicted/file
git status

您将看到一行(通常是绿色)显示修改后的文件

修改:你/冲突/文件

Git rebase -continue在这种情况下可以正常工作。

然而，有时在解决冲突时，您会删除新补丁中的所有内容，只保留重新基于的分支的代码。现在，当您添加文件时，它将与您试图重新基于的文件完全相同。Git状态不会显示绿色线显示修改后的文件。现在，如果你知道

git rebase --continue

Git会抱怨

没有变化-你忘记使用'git add'了吗?

如果您确定已经添加了所有更改, git实际上想让你在这种情况下做的是使用

git rebase --skip

跳过补丁。以前我从来没有这样做过，因为我总是不确定如果我这样做的话，实际上会跳过什么，这对我来说并不明显。真正的意思。但如果你没有绿线

修改:你/冲突/文件

在编辑冲突文件添加它并执行git status之后，那么你可以相当肯定你删除了整个补丁，并且你可以使用

git rebase --skip

继续。

最初的帖子说，这种方法有时有效:

git add -A
git rebase --continue
# works magically?

．.． 但不要依赖于此(并确保不要在存储库文件夹中添加剩余文件)

小开

在修复冲突之后，确保将更改的文件添加到暂存文件中。这为我解决了问题。

小开

当我有未分级文件时，我得到了这个警告。确保没有任何非暂存文件。如果不希望更改非暂存文件，则使用

git rm <filename>
小开
我只是偶然发现了这个问题。我不会git rebase --skip 因为git status清楚地显示了分期修改，这是我想保留的。虽然我有一些意外的额外文件。我解决了

git checkout .

来删除未分段的修改，则git rebase --continue成功。

小开

一旦你修正了你的改变你可能会忘记运行'git add -A'

git add -A
git rebase --continue
小开

如果您正在使用magit(一种流行的emacs git前端)，则此错误消息可能是由于magit中的一个模糊错误而显示的。我不太确定是什么触发了这个错误，但对我来说，这是一个文件只有行结束符被改变了，所以magit没有显示该文件为冲突。所以我以为已经没有矛盾了，但其实有。在命令行上运行git status可以让我看到冲突的文件，然后我可以运行git add 文件名，然后运行git rebase --continue。

小开

公认的答案具有误导性。它造成的麻烦比它可以避免的要多(参考注释)。

我意识到git rebase --continue不适合我，因为我修改了一些本地文件，但没有登台。运行下面的抑制了我的局部的、无阶段的修改。所以请小心，这就是你想要的。

git checkout .

如果你想要进行修改，运行git add <name of the file>。

如果你想隐藏(搁置)修改，运行git stash -k。

在这两个命令后运行git rebase --continue应该可以工作。

如果你选择保存，运行git stash pop(在git rebase --continue之后)来恢复修改。


提交答案