如何正确地将不同的“开发”分支合并到主分支中？

Question

我有一个 master 分支和另外两个分支，“dev1”和“dev2”都是从 master 创建的。但是如果 person1 修改了一行并推送到 dev1 中，然后创建一个合并请求到 master 分支，它不会显示合并冲突，只是显示一行被更改为新值。然后如果还没有执行 git pull 的 person2 执行 git push 到 dev2 分支，然后创建一个合并请求到 master，则由 person1 修改的行将再次修改为 person2 仍然拥有的旧值他们的存储库。

但是，如果我创建从 dev2 到 dev1 的合并请求，那么它将显示更改的值的合并冲突。我很困惑为什么它只在我尝试合并这两个时才显示，而不是在我尝试合并到 master 分支时显示。

谁能解释我做错了什么以及合并的正确方法是什么？谢谢。

Answer 1

一般来说，当 2 个人修改同一段代码时，没有办法绕过手动合并冲突解决的需要。毕竟，git 应该如何知道哪个分支是“正确的”分支？使用像 -s theirs 或 -s ours（或非递归 -ours）这样的递归合并策略可能没问题，但这些是“焦土”合并方法，它们并没有真正触及问题：我们如何在同一个文件上采用 2 个不同的变更集，自动将它们合并在一起，并最终得到有效的东西（更不用说按作者预期的方式工作了......）？文件上的冲突更改通常需要手动处理； Git 很聪明，但没那么聪明......

让我们看看你的例子。

Person1 和 Person2 从 master 创建自己的分支。 hack hack hack。 Person1 提交并推送一些更改。 Person2 尚未拉取最新更改（由 Person1 进行的更改），尝试推送与 master 分支的最新版本冲突的更改集。这些更改将被远程存储库（可能是 Github）拒绝，因为存在冲突，并且 Person2 正在尝试推送缺少来自 Person1 的提交的更改。

如果 Person2 在 push 之前尝试将 Person1 所做的更改合并到自己的分支中，它们仍然会发生冲突。但在这种情况下，Person2 将能够手动对其进行排序（也许在 Person1 的帮助下），以便下一次推送将包括两个更改集，干净地合并，并且 git 将再次感到高兴。

---

我只是更仔细地重新阅读了这篇文章，并注意到您没有提及 Person1 提出的合并请求是否在 Person2 提出第二个请求时实际上已经合并。

如果来自 Person1 的合并尚未未合并，那么首先由于这些提交，任何一个分支都不会发生合并冲突。实际上，这两个分支仍然处于平等地位，争先恐后地合并它们的更改：获胜者将获得干净的合并，而剩下的未决分支将与这些更改发生冲突。

之所以如此，是因为 Git/Github 只是比较源分支和目标分支（dev1 <--> master 和 dev2 <--> master）。它不会将待处理的拉取请求相互比较。事实上，使用git¹ 确实无法比较 2 个拉取请求，因为整个“拉取请求”概念纯粹存在于 Github 中。 Git 不了解拉取请求，因此在其中一个合并完成之前，git 中实际上不会发生任何变化，也不存在合并冲突。

但在这两种情况下，迟早都会出现合并冲突。这只是何时会发生的问题：

• dev1 --> master 后跟dev2 --> (conflict) --> master

• dev1 --> (conflict) --> dev2 --> master

---

_{1 不是相当正确：这两个分支上的底层提交可以在 GitHub 上或使用 git diff 进行比较，但在将拉取请求合并到第三个分支（也不应该是）。}