Question

我们在Github上有一个存储库。一位用户创建了一个分支，将其签到Github，并创建了一个拉取请求。当他登录Github并查看PR时，底部会显示一条消息，提示没有冲突，并且可以合并此PR。有一个绿色按钮可以做到这一点。

当我登录Github并查看相同的PR时，会看到不同的消息：“由于冲突，该分支无法重新建立基础。由于冲突，无法自动执行将该分支的提交重新置于基础分支之上重新应用来自head分支的单个提交时遇到的问题。”

为什么我们看不到相同的东西？

我们的登录名和配置选项有什么不同吗？

他在他的IDE中可能有不同的选择，但这没有什么不同。 Github上只有一个版本的仓库。他在Windows上，而我在Mac上，但这也不应该有所不同。

在尝试重新本地化之前，有没有办法让我看到冲突到底是什么？

Answer 1

如果一个修订版本添加的代码是冲突生成器，而另一个修订版本又将其收回，则可能存在基准冲突，而没有合并冲突。如果合并，则该分支不会具有冲突的代码...但是，如果您逐个修订（如在变基中），则必须处理两次冲突。

Answer 2

问题下方的注释中指出，这是因为GitHub提供了合并的提交给没有问题的人，但是对您来说，GitHub提供了 rebase 提交。有时，合并很容易，而重新设置则不容易。

这是提交系列的一个简单示例，可以轻松合并，但不能重新建立基础。首先，让我们绘制实际的提交图：

...--G--H------L   <-- master
         \
          I--J--K   <-- branch

在提交H中，文件makeconfict的内容如下：

This is line 1
This is line 2
This is line 3

在提交L中，我们将第2行更改为This is line two。因此H-vs-L更改了文件makeconflict的第2行（并且没有其他更改）。

与此同时，在提交I中，我们删除文件makeconflict的第2行。在提交J中，我们对一些有用的文件进行了有用的更改，而没有涉及文件makeconflict。在提交K中，我们将文件makeconflict的第2行放回去。

如果我们尝试merge（分支K的尖端branch到master中，则Git比较H与L并发现makeconflict的第2行已更改。它将H与K进行比较：这表示我们必须从H更改文件makeconflict的第2行，以保留在master中所做的更改。然后将H与K进行比较，看看我们做了什么。由于我们将第2行放回K中，因此，唯一的 change Git需要与对makeconflict的更改结合起来，即对重要文件的更改。这样合并可以顺利进行，更改重要文件，我们得到：

...--G--H------L--M   <-- master (HEAD)
         \       /
          I--J--K   <-- branch

但是，如果我们尝试重新构建，则Git需要将提交I复制到I'之后的新提交L：

                 I' [in progress, not actually committed yet]
                /
...--G--H------L   <-- master
         \
          I--J--K   <-- branch

尝试将I复制到I'（与H到I的区别）表示我们必须删除文件的第2行makeconflict，而H和L之间的区别在于，我们必须更改文件makeconflict的第2行。这两个不同的更改相互冲突。我们必须选择要进行的更改：将2替换为two，还是完全删除该行？

如果我们完全删除该行（这需要人工干预，而GitHub不会通过Web UI进行删除），则可以继续将J复制到J'和K到K'：

                 I'-J'-K'   <-- branch (HEAD)
                /
...--G--H------L   <-- master
         \
          I--J--K   [abandoned]

在此过程中，我们将文件makeconflict的第2行放回了原来的状态，现在仍在废弃的提交K中。因此，我们遇到一个合并冲突（将I复制到L上以制作I'），实际上，最终是撤消了L中所做的更改。但是一旦完成，我们就会有一系列提交，这些提交只会直接添加到master中，因此我们可以使用master将名称K'提前提交到git checkout master; git merge --ff-only branch ：

...--G--H------L--I'-J'-K'   <-- branch, master (HEAD)
         \
          I--J--K   [abandoned]

或者，当然，当在I'处理合并冲突时，我们可以选择舍弃对I的更改，并保留L的更改。最后，我们只是跳过完全复制I。当我们将提交K复制为K'时，通常会遇到另一个合并冲突，尽管有时Git会意识到也不需要提交K。如果我们正确处理了冲突，我们也会删除K：

                 J'  <-- branch (HEAD)
                /
...--G--H------L   <-- master
         \
          I--J--K   [abandoned]

同样，我们现在可以快进master指向复制J'。

这个示例当然是人为的，但是这些事情确实确实发生在现实生活中。

Github告诉一个用户存在冲突，但不告诉其他用户

2 个答案: