Git 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 #
当我做混帐rebase – 继续我得到：
git rebase --continue You must edit all merge conflicts and then mark them as resolved using git add
我知道我可以跳过修补程序并继续修改底纹，但是我不确定PassengerContactHandler.java中的更改是否会重新join到我的分支中。
所以我不确定，我应该怎么做？
编辑：难道是解决冲突的文件是完全一样的原始版本？
非常感谢，卢卡斯
编辑，它再次发生在我身上：
这又发生在我身上，
(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 –continue
You must edit all merge conflicts and then mark them as resolved using git add
git –version
git version 1.7.1
发生这种情况是因为在修复冲突时，您删除了应用到您正在重新分配的分支的修补程序中的所有代码。 使用git rebase --skip继续。
更多的细节：
通常情况下，在重新绑定期间修复冲突时，您将编辑冲突文件，并将修补程序中的部分或全部代码当前应用于分支的分支。 修补补丁后，
git add your/conflicted/file git status
你会得到一个（通常是绿色的）行显示修改后的文件
修改：你的/冲突/文件
git rebase – continueue在这种情况下可以正常工作。
然而，有时在解决冲突时，会删除新修补程序中的所有内容，只保留来自重新分支的分支的代码。 现在当你添加文件的时候，就会和你想要的那个一样。 git状态将显示没有绿线显示修改的文件。 现在，如果你这样做
git rebase --continue
git会抱怨
没有变化 – 你忘了使用'git add'？
在这种情况下，git真正希望你做的是使用
git rebase --skip
跳过补丁。 以前我从来没有这样做，因为我一直不确定如果我真的跳过了什么，我不知道什么“跳过这个补丁”真的意味着什么。 但是，如果你没有绿线
修改：你的/冲突/文件
编辑冲突的文件后，添加它，并做git状态，那么你可以肯定你删除了整个补丁，你可以改为使用
git rebase --skip
接着说。
原来的post说这有时候起作用：
git add -A git rebase --continue # works magically?
…但不要依赖于此（并确保不要在您的存储库文件夹中添加剩余的文件）
似乎是Git 1.7中的一个bug
这里有一篇关于如何解决这个问题的好文章 。
基本上它应该工作，如果你做了
git diff
解决你的冲突后，然后
git rebase --continue
应该pipe用。
我刚刚有这个问题，虽然我认为可能有一些原因，这是我的…
我有一个git pre-commit钩子在一定条件下拒绝提交。 当手动提交时，这很好，因为它会显示钩子的输出，我可以修复它，或者使用commit –no-verifyselect忽略它。
问题似乎是，当重新定位，重新设定 – 继续也将挂钩（为了执行最新的变化）。 但rebase不会显示钩子输出，它只会看到它失败，然后吐出一个不太明确的错误，说'你必须编辑所有合并冲突，然后标记为解决使用git add'
为了解决这个问题，把所有的改变都放在一边，而不是去做“git rebase -continue”，试试git commit。 如果你遇到同样的问题，那么你应该看到失败的原因。
有趣的是，尽pipegit rebase没有显示git钩子的输出，但它确实接受了–no-verify来绕过钩子。
尝试在你的命令行中运行这个：
$ git mergetool
应该提出一个交互式编辑器，让你解决冲突。 比手动执行更容易，git也会识别你什么时候进行合并。 还可以避免在您尝试手动执行时不会意外完全融合的情况。
您错过了AssetsLoader.java中的合并冲突。 打开它并查找冲突标记（“>>>>”，“====”，“<<<<<”），然后再做git添加。 如果你很难find它，请做一个'git diff –staged'。
解决冲突之后，确保已更改的文件已添加到您的暂存文件中。 这解决了我的问题。
