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

After fixing conflicts git still complains?

提问by JP Silvashy

I usually rebasewhen I pull in changes from my teammates, and often time I have conflicts:

我通常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".

So after opening each file with a conflict, fixing it then committing the fixed files:

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

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

I still get the same error...

我仍然遇到同样的错误...

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

I've sort-of always had this problem, but I guess never really chose to address it, I would I always just get lazy and git rebase --skip.

我一直有这个问题，但我想从来没有真正选择解决它，我会总是变得懒惰并且git rebase --skip.

How do I actually resolve the conflict the right way?

我如何真正以正确的方式解决冲突？

回答by Mark Rushakoff

So after opening each file with a conflict, fixing it then committing the fixed files...

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

The problem is that you aren't supposed to committhe fixes. If a.txthas a merge conflict, then your shell log should look like:

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

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

Calling git rebase --continuewill take care of the commit itself.

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

I'm not sure how to "get back" to before your commit, when you're in the middle of a rebase. git reset --hard HEADwould probably do the trick, but personally I'd feel safer just going straight to git rebase --abortand starting over without committing in the middle.

当您处于变基过程中时，我不确定如何在提交之前“返回”。 git reset --hard HEAD可能会做到这一点，但就我个人而言，我觉得直接开始git rebase --abort并重新开始而不在中间做出承诺会更安全。

回答by sage

I agree with Mark Rushakoff that fixing commits should not include committing them.

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

There is at least one other way that git will continue to say that "You must edit all merge conflicts and then mark them as resolved using git add" even after you have done just this. This may occur if you remove files from git version control, but leave the unversioned file sitting in your working tree and then try to perform a rebase.

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

I was able to fix this problem as follows:

我能够解决这个问题如下：

1. Terminate rebase with git rebase --abort
2. Determine offending file by looking at git status
3. I moved my unversioned files to my tmpdirectory
4. Redo the rebase - in my case git svn rebase
5. If you want the unversioned file hanging around, move it back where you want it (I left mine in my tmp directory)

1. 终止变基 git rebase --abort
2. 通过查看确定有问题的文件 git status
3. 我将未版本控制的文件移动到我的tmp目录
4. 重做变基 - 就我而言 git svn rebase
5. 如果您想要未版本化的文件挂起，请将其移回您想要的位置（我将我的文件留在了我的 tmp 目录中）

Hope that helps.

希望有帮助。

回答by Gil

When this happened to me, I managed to solve it after realizing I had edited (and added to the index) during the rebase a file which does not have a conflict, I guessed this might be wrong. So I used git checkout -- <filename-with-no-conflict>, and then git rebase --continue, and it worked.

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

回答by VonC

With Git 2.14 (Q3 2017), this kind of advice given in a rhetorical question that does not require an answer (like "did you forget to use 'git add'?") will be no more.

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

See commit 6963893, commit 9932242, commit 6c48686(11 May 2017) by Jean-Noel Avila (jnavila).
^{(Merged by Junio C Hamano -- gitster--in commit e638108, 29 May 2017)}

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

usability: don't ask questions if no reply is required

可用性：如果不需要回复就不要问问题

When the spelling of a command contains errors, the git program tries to help the user by providing candidates which are close to the unexisting command. E.g Git prints the following:

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

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

    stash

and then exits.

然后退出。

The problem with this hint is that it is not formally indicated as an hint and the user is in fact encouraged to reply to the question, whereas the Git command is already finished.

The user was unlucky enough that it was the command he was looking for, and replied "yes" on the command line, effectively launching the yesprogram.

The initial error is that the Git programs, when launched in command-line mode (without interaction) must not ask questions, because these questions would normally require a user input as a reply that they won't handle indeed. That's a source of confusion on UX level.

To improve the general usability of the Git suite, the following rule was applied:

if the sentence

• appears in a non-interactive session
• is printed last before exit
• is a question addressing the user ("you")

the sentence is turned into affirmative and proposes the option.

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

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

最初的错误是 Git 程序在以命令行模式（无交互）启动时不能提出问题，因为这些问题通常需要用户输入作为他们不会真正处理的答复。这是 UX 级别的混淆来源。

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

如果这句话

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

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

In your case, "did you forget to use 'git add'?" is now replaced with:

在您的情况下，“ did you forget to use 'git add'?”现在替换为：

You should 'git add' each file with resolved conflicts to mark them as such.
You might run git rmon a file to accept "deleted by them" for it.

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

Much clearer.

清楚多了。

回答by vladiim

I found myself in the same boat and git rebase --continuedidn't help. Running rm -fr .git/rebase-applyfixed the issue though

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