我有一个master分支，以及另外两个从master创建的分支“ dev1”和“ dev2”。但是，如果person1修改一行并推送到dev1，然后将合并请求创建到master分支中，则不会显示合并冲突，仅显示将一行更改为新值即可。然后，如果尚未执行git pull的person2，将git push到dev2分支，然后将合并请求创建到master，则person1修改的行将再次修改为person2仍具有的旧值他们的资料库。
但是，如果我创建了一个从dev2到dev1的合并请求，那么它将显示已更改值的合并冲突。我很困惑为什么它只在我试图合并这两个时才显示，而在我尝试合并到master分支时却不显示。
有人可以向我解释我做错了什么，以及合并的正确方法是什么？谢谢。
答案 0 :(得分：1)
通常，当2个人修改相同的代码位时，不需要手动合并冲突解决方案。毕竟，git应该如何知道哪个分支是“正确的”分支？使用诸如-s theirs或-s ours（或非递归-ours）之类的递归合并策略可能是可以的，但是这些是“焦土”合并的方法，它们实际上并没有问题的核心：我们如何在同一个文件上使用2个不同的变更集，将它们自动合并在一起，最后得到一些有用的东西（少了作者想要的工作方式...）？文件上冲突的更改通常需要手动处理。 Git很聪明，但不是那么聪明。...
让我们看看您的示例。
Person1和Person2在master之外创建自己的分支。 hack hack hack 。 Person1提交并推送一些更改。未拉出最新更改（由Person1进行的更改）的Person2尝试推送与主分支的最新版本冲突的更改集。这些更改将被远程存储库（可能是Github）拒绝，因为存在冲突，并且Person2尝试推送缺少Person1提交的更改。
如果Person2在推送之前尝试将Person1所做的更改合并到自己的分支中，则它们仍然会发生冲突。但是在这种情况下，Person2将能够手动对其进行排序（也许在Person1的帮助下），以便下一次推送将包括两个变更集（干净地合并），而git将再次感到高兴。
我只是更仔细地重读了一下，并注意到您没有提到在Person2提出第二个请求时，Person1提出的合并请求是否实际上已被合并。
如果来自Person1的合并还没有尚未被合并，那么由于这些提交，首先，任何一个分支都不会发生合并冲突。实际上，这两个分支在争取首先合并其变更的竞赛中仍然处于平等的基础上：获胜者将获得干净的合并，然后剩下的一个将与那些变更冲突。
之所以这样工作，是因为Git / Github仅比较源分支和目标分支（dev1 <--> master和dev2 <--> master）。它不会将挂起的拉取请求彼此进行比较。实际上，实际上没有办法使用git 1 比较2个拉取请求，因为整个“拉取请求”概念完全存在于Github中。 Git对拉取请求一无所知，因此，直到其中一个合并完成，git中的内容实际上都不会改变，并且不会存在任何合并冲突。
但是在这两种情况下，迟早都会发生合并冲突。只是何时会发生的问题：
dev1 --> master后跟dev2 --> (conflict) --> master
dev1 --> (conflict) --> dev2 --> master
1不是 quit 是：可以在GitHub上或使用git diff来比较这两个分支上的基础提交，但是合并合并请求时不会考虑到第三个分支（也不应该）。
答案 1 :(得分：-1)
如果在将dev分支合并到master之前将master合并到dev分支，则没有问题。