修复冲突后，git 仍然抱怨？答案

【问题标题】：After fixing conflicts git still complains?修复冲突后，git 仍然抱怨？
【发布时间】：2010-08-31 16:49:35
【问题描述】：

当我从队友那里拉取更改时，我通常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。

我该如何以正确的方式实际解决冲突？

【问题讨论】：

标签： git

【解决方案1】：

所以在打开每个有冲突的文件后，修复它然后提交修复的文件......

问题是您不应该commit 修复。如果a.txt 有合并冲突，那么你的shell 日志应该是这样的：

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

调用git rebase --continue 将处理提交本身。

当您处于变基中间时，我不确定如何“返回”到您的提交之前。 git reset --hard HEAD 可能会成功，但我个人觉得直接去git rebase --abort 并重新开始而不在中间提交会更安全。

【讨论】：

是的，我同意...我想我并没有真正阅读错误消息（按照我通常的工作流程），git rebase --abort 解决了眼前的问题。再次感谢！
乐于助人！ git 有时肯定会有点令人困惑，但我不知道没有它我是如何生存下来的。

【解决方案2】：

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

至少还有另一种方式，git 会继续说“您必须编辑所有合并冲突，然后使用 git add 将它们标记为已解决”，即使您已经这样做了。如果您从 git 版本控制中删除文件，但将未版本化的文件留在工作树中，然后尝试执行变基，则可能会发生这种情况。

我能够通过以下方式解决此问题：

使用git rebase --abort 终止rebase
通过查看git status 确定违规文件
我将未版本控制的文件移到了我的 tmp 目录中
重做rebase - 在我的情况下git svn rebase
如果您希望保留未版本控制的文件，请将其移回您想要的位置（我将我的留在我的 tmp 目录中）

希望对您有所帮助。

【讨论】：

【解决方案3】：

当这发生在我身上时，我意识到我在变基期间编辑（并添加到索引中）一个没有冲突的文件后，我设法解决了这个问题，我猜这可能是错误的。所以我使用了git checkout -- <filename-with-no-conflict>，然后是git rebase --continue，它成功了。

【讨论】：

【解决方案4】：

在 Git 2.14（2017 年第三季度）中，这种在不需要回答的反问中给出的建议（如“did you forget to use 'git add'?”）将不再存在。

参见Jean-Noel Avila (jnavila) 的commit 6963893、commit 9932242、commit 6c48686（2017 年 5 月 11 日）。
^{（由 Junio C Hamano -- gitster -- 合并到 commit e638108，2017 年 5 月 29 日）}

可用性：如果不需要回答就不要提问

当命令的拼写包含错误，git程序试图通过提供候选人来帮助用户接近不存在的命令。例如 Git 打印以下：

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

    stash

然后退出。

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

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

最初的错误是 Git 程序在启动时命令行模式（无交互）不得提问，因为这些问题通常需要用户输入作为回复他们确实不会处理。这是 UX 混乱的根源级别。

为了提高 Git 套件的一般可用性，以下规则已应用：

如果句子

出现在非交互式会话中

在退出前最后打印

是针对用户（“您”）的问题

句子变成肯定句并提出选项。

在你的情况下，“did you forget to use 'git add'?”is now replaced with：

您应该“git add”每个已解决冲突的文件来标记它们。
您可以在文件上运行 git rm 以接受“被他们删除”。

更清晰。

【讨论】：

【解决方案5】：

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

您有未合并的路径。

我所要做的就是git add <file that had conflicts>，一切都很好。

【讨论】：

【解决方案6】：

我发现自己在同一条船上，git rebase --continue 没有帮助。运行 rm -fr .git/rebase-apply 解决了这个问题

【讨论】：

我提醒人们不要这样做。我试过了，它似乎已经淹没了我的分支，我无法撤消这个（试过git rebase --abort然后git reset --hard HEAD）。甚至git reflog 似乎也没有展示我之前的工作（rebase 之前在分支上的最后一次提交）。在我的 IDE 的帮助下重建我的补丁，谢天谢地，在删除/更新我刚刚吹走的文件和更改之前，它询问了。
仔细查看git reflog 输出并找到我的提交，我也可以通过检查原始分支（在使用git checkout -b new_branch_name 保存我的分离头部混乱之后）来实现。考虑到它在我的情况下造成的混乱，我仍然对此持谨慎态度。