为什么合并冲突会发生？

例如:

我有一个主分支.

我创建了一个文件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分支合并时为什么没有合并文件(为什么文本不是像修补程序一样被替换)？为什么基本上这种冲突第二次发生而不是第一次？

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

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

当您尝试合并第二个更改时,不再是这样:通过合并第一个分支,您已经引入了与第二个分支中的更改不直接"兼容"的master更改.Git称之为:"分支机构已经分歧".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永远不会在这种情况下做出自动决定.