为什么合并冲突会发生？

Question

例如：

• 我有一个主分支。
• 我创建了一个文件file.txt并在其中写了Master branch，然后我提交了它。
• 我创建了另一个名为fix20的分支，并将file.txt的文本修改为This is fix20 branch。然后我承诺了。
• 我切换到主分支，然后创建分支hotfix并切换到它。
• 我修改file.txt以获得文字This is the HotFix。之后，我提交了更改。
• 现在我切换回主分支并将其与修补程序合并。该文件（没有问题）将其文本更改为This is the HotFix（它们基本上是合并的））。

现在我与fix20分支合并，我得到了合并冲突。 file.txt包含fix20分支中的文本和与HotFix合并后的文本。在这一点上，我应该打开一个编辑并决定，应该留下什么，以及应该删除什么。

问题是：为什么合并冲突第二次发生？当我将主服务器与修补程序合并时，为什么我没有决定要留下哪些文本？当我与fix20分支合并时为什么没有合并文件（为什么文本不是像修补程序一样被替换）？为什么基本上这种冲突第二次发生而不是第一次发生???

Answer 1

这里的问题是你知道你的意图......但是Git没有。

这就是Git如何看待你所做的事情：你对同一行进行了两次独立的更改。当您合并第一个时，您的意图很明确：您希望更改成为master的一部分。由于你已经分支，所以主人自己没有任何变化，因此没有问题：如果只有合并的一方改变了它，Git总是可以直接合并一段代码

当您尝试合并第二个更改时，这不再是真的：通过合并第一个分支，您已经引入了不直接＆＃34;兼容＆＃34;随着第二个分支的变化。 Git称之为：＆＃34;分支机构发生了分歧＆＃34;。 Git不知道你是否要保留你从第一个分支合并的东西，或者你要从第二个分支合并的东西。

在你的情况下它显而易见给你，因为第二个分支是同一个东西的新修复......但是许多合并涉及更复杂的代码更改，也许是合并第二个分支的正确方法是合并来自两个合并的更改：通常，如果两个合并的更改触及同一行代码，则两者都必须在其上留下标记。

示例原始代码：

send_request("bake cookies")

分支1：

send_request("bake cookies", additions: ["chocolate"])

分支2：

send_request("bake cookies", flour: "wheat")

合并这两者的正确方法可能不是逐字地取两条线之一，它可能更像是这样：

send_request("bake cookies", flour: "wheat", additions: ["chocolate"])

由于您比Git更了解代码的意图，因此Git永远不会在这种情况下做出自动决定。

Answer 2

阅读this answer了解详情。它有同样的问题，但情况略有不同

简而言之：

答案是存在冲突，因为2个分支没有merge-base提交。

以下是您描述的步骤

我使用3-diff广告差异算法

以下是文件的内容：

<<<<<<< HEAD
This is hotfix branch
||||||| merged common ancestors
Master branch
=======
This is fix20 branch
>>>>>>> fix20

我试图为您的问题生成一些图形演示，但这需要花费太多时间。

我试着尽可能清楚地回答这里。

因为每当你做一个合并git时你有几个分支，试着找出拆分的位置（你在哪个提交上派生并打开了新的分支）。然后从这一点开始生成diff并尝试合并文件。

我的情况我们有这个：

master            master  master
   \----- hotfix --- /     |
   |                       |
   \----- fix20  ----------/


// To view the patch that will be created for the merge you can run
// this command and you will see the commits that will be merged.
git log ^master fix20 

在您的情况下，您将看到它尝试合并更新同一文件的提交（两个分支都是从同一个提交[merge-base commit]创建的），并且会导致冲突。