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。

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

Answer 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并重新开始，而不是在中间进行。

Answer 2

我同意Mark Rushakoff的说法，即修复提交不应包括提交它们。

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

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

使用git rebase --abort
查看git status
我将未版本控制的文件移到我的tmp目录
重做基础 - 在我的情况下git svn rebase
如果您希望无版本文件闲置，请将其移回您想要的位置（我将其保存在我的tmp目录中）

希望有所帮助。

Answer 3

当我遇到这种情况时，我意识到我已经在rebase期间编辑（并添加到索引）没有冲突的文件后设法解决了，我猜这可能是错误。所以我使用git checkout -- <filename-with-no-conflict>，然后使用git rebase --continue，它就有用了。

Answer 4

使用Git 2.14（2017年第3季度），在一个不需要答案的修辞问题中给出的这种建议（例如＆＃34; did you forget to use 'git add'?＆＃34;）将不复存在。

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

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

当命令的拼写包含时错误，git程序试图通过提供候选人来帮助用户这是接近现有的命令。 E.git打印出来以下内容：

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

    stash

然后退出。

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

用户不幸的是，这是他正在寻找的命令   for，and reply＆＃34; yes＆＃34;在命令行上，有效地启动了   yes计划。

最初的错误是Git程序在启动时   命令行模式（没有交互）不能提问，   因为这些问题通常需要用户输入作为回复   他们确实无法胜任。这是UX的混乱之源   水平。

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

如果句子


出现在非交互式会话中

在退出前最后打印

是针对用户的问题（＆＃34;你＆＃34;）


这句话变成了肯定的并提出了选择。

在您的情况下，＆＃34; did you forget to use 'git add'?＆＃34; is now replaced with：

你应该git add＆＃39;每个已解决冲突的文件都标记为这样您可以在文件上运行git rm以接受＆＃34;由他们删除＆＃34;为了它。

更清楚。

Answer 5

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

<块引用>

您有未合并的路径。

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

Answer 6

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

修复冲突后git还在抱怨吗？

6 个答案:

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