解决了冲突，但Git仍然抱怨？

Question

每当我从我的队友那里拉取更改时，我通常会使用rebase，但经常会出现冲突:

...
CONFLICT (content): Merge conflict in app/views/search/index.html.erb
Auto-merging public/stylesheets/application.css
CONFLICT (content): Merge conflict in public/stylesheets/application.css
Failed to merge in the changes.
Patch failed at 0001 organizing

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

所以，在打开每个存在冲突的文件后，进行修复并提交已修复的文件之后：

~/Projects/myApp[956f6e1...]% git rebase --continue
You must edit all merge conflicts and then
mark them as resolved using git add

我仍然收到相同的错误信息...

~/Projects/myApp[64b3779...]% git rebase --continue                         
Applying: organizing
No changes - did you forget to use 'git add'?

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

我一直有这个问题，但我似乎从未选择解决它，通常我都会变得懒惰并执行 git rebase --skip 命令。

我应该如何正确地解决冲突？

- JP Silvashy

Answer 1

所以，在打开每个有冲突的文件、修复它并提交修复后，问题在于你不应该提交这些修复。如果 a.txt 存在合并冲突，那么你的 shell 日志应该像下面这样：

$ vim a.txt # fix conflict
$ git add a.txt
$ # no commit between add and rebase!
$ git rebase --continue

执行git rebase --continue命令将处理提交本身。

当你在rebase过程中想回到提交之前时，我不确定该怎么做。 git reset --hard HEAD可能是一个解决方法，但就我个人而言，我更愿意直接使用git rebase --abort并重新开始而不在中途提交。

- Mark Rushakoff

---

是的，我同意... 我想我并没有真正读错误信息（按照我的常规工作流程），git rebase --abort 解决了即时问题。再次感谢！ - JP Silvashy

很高兴能帮忙！有时候Git确实会让人有点困惑，但我不知道我以前是怎么没有它活下来的。 - Mark Rushakoff

Answer 2

我同意Mark Rushakoff的观点，修复提交不应该包括提交它们。

Git会在你已经解决所有合并冲突并使用git add标记为已解决后，仍然继续提示“您必须编辑所有合并冲突并使用git add标记为已解决”。这可能发生在你将文件从git版本控制中删除，但保留未版本化的文件在工作树中，然后尝试执行rebase的情况下。

我解决了这个问题，步骤如下：

1. 用git rebase --abort终止rebase
2. 通过查看git status确定有问题的文件
3. 将未版本化的文件移动到我的tmp目录中
4. 重新进行rebase - 在我的情况下为git svn rebase
5. 如果你想要未版本化的文件，将其移回到你想要的地方（我将我的文件放在了tmp目录中）

希望这能帮到你。

- sage

Answer 3

当这种情况发生在我身上时，我意识到我在rebase期间编辑并添加到索引中的文件没有冲突，我猜想这可能是错误的。所以我使用git checkout -- <filename-with-no-conflict>，然后git rebase --continue，然后它就可以正常工作了。

- Gil

Answer 4

我遇到了合并冲突，但我已经解决了，然而我仍然看到

您有未合并的路径。

我所要做的就是 git add <存在冲突的文件>，然后一切都顺利进行了。

- stevec

Answer 5

在 Git 2.14 (Q3 2017) 中，类似“你是否忘记使用 'git add'？”这样的修辞问题将不再存在。

请查看提交 6963893, 提交 9932242, 提交 6c48686 (2017年5月11日) 由Jean-Noel Avila (jnavila)提交。
^{(由Junio C Hamano -- gitster --合并于提交 e638108, 2017年5月29日)}

可用性：如果不需要回复，请勿提问

当命令的拼写存在错误时，git程序会尝试通过提供接近不存在命令的候选项来帮助用户。例如，Git会打印以下内容：

    git: 'stahs' is not a git command. See 'git --help'.
    Did you mean this?

    stash

然后退出。

这个提示的问题在于它没有被正式标识为提示，实际上鼓励用户回答问题，而 Git 命令已经完成了。

用户不幸的是，这正是他正在寻找的命令，并在命令行上回答了“yes”，有效地启动了 yes 程序。

最初的错误在于，当以命令行模式（无交互）启动 Git 程序时，它们不应该询问问题，因为这些问题通常需要用户输入回复，而它们确实无法处理。这是 UX 层面的混淆源。

为了提高 Git 套件的通用性，应用了以下规则：

如果句子

• 出现在非交互式会话中
• 在退出前最后打印
• 是一个针对用户（“you”）的问题

该句子将转换为肯定形式并提供选项。

在你的情况下，"did you forget to use 'git add'?" 现在被替换为：

你应该使用 'git add' 命令将每个解决冲突的文件标记为已解决。
你可以对一个文件运行 git rm 命令来接受 "deleted by them" 的更改。

清晰明了。

- VonC

Answer 6

我发现自己也遇到了同样的问题，git rebase --continue 也没有帮助。不过运行 rm -fr .git/rebase-apply 解决了这个问题。

- vladiim

---

我警告人们不要这样做。我尝试了一下，似乎搞砸了我的分支，我无法撤销这个操作（尝试了git rebase --abort和git reset --hard HEAD）。即使使用git reflog命令，也似乎无法显示我之前的工作（重整之前分支上的最后一次提交）。幸运的是，我的IDE帮助我重新构建了我的补丁，它在删除/更新文件和更改之前询问了我。 - sage

仔细查看了 git reflog 的输出，找到了我的提交记录，我也可以通过检出原始分支（在使用 git checkout -b new_branch_name 保存我的分离头混乱之后）来获取它们。尽管如此，我仍然警告不要这样做，因为在我的情况下会造成很大的混乱。 - sage