为什么git中需要3路合并时需要公共祖先？

我是git新手，我了解什么是快进合并[如果两个分支是线性的，只需将指针移到分支]但是当涉及到三路合并时，我有点困惑，因为为什么三路合并需要公共祖先来创建新的提交为什么不能接受两个分支[我想要合并到的分支（例如：master））和一些想要合并的分支（例如：immediatefix）并比较它们，然后只进行合并。。为什么要使用共同祖先。在rebase中，我们为什么需要共同祖先…

这很简单，可以归结为Git存储是如何提交的。与其他VCS不同，Git存储整个工作目录的完整快照。因此，当查看单个提交时，您所能看到的只是该提交中内容的确切状态

其他风险投资公司，如Subversion，通常会存储差异。因此，修订将存储为前一状态和当前状态之间的差异。因此，当合并时，您只需查看单个修订，就可以看到发生了什么，您可以将其应用到其他地方

另一方面，Git没有现成的差异。为了能够看到提交中发生了什么，它需要将内容与父提交进行比较。只有这样，它才能产生差异并将其应用到其他地方。因此，对于两个具有共同基础

C

的分支

A

和

B

，Git所做的是查看

A

和

C

之间的差异，以及

B

和

C

。然后它知道每个分支中到底发生了什么，并可以尝试应用所有更改。这样做还有一个好处，就是可以查看整个范围的更改，因此，如果您临时更改了一个分支中的某个内容，但后来又取消了该分支，则在合并时不会出现完全的差异。这通常会减少冲突

这同样适用于折扣，只是它实际上是以折扣的名义出现的。当将

B

重定基址到

A

上时，基本上是重写范围

C..B

中的所有提交，以将

A

作为父级。因此Git将查看

C

和分支上的第一次提交之间的差异，并将其应用于

A

。然后，它将查看第一次提交和第二次提交之间的差异，并应用该差异。这种情况一直持续到整个分支被重新设置为以

A

为基础

---

这就是我感到困惑的地方，如果A有完整的快照，B有完整的快照，我们可以比较A和B，我们可以合并它，那么为什么我们需要公共基C

好吧，让我们来举个例子。我们将只查看一个文件以使其更简单，但存储库中的每个文件都会出现这种情况

假设这是分支A中的文件内容：

alpha
beta
gamma

这是分支B中的内容：

alpha
gamma
delta

现在合并后的版本会是什么样子？如果您不知道提交实际上改变了什么，您就不能安全地决定这一点。例如，我们可以说，文件最初（在C中）只有

alpha

和

gamma

。因此在分支中添加了A

beta

，在B

delta

中添加。这将导致：

alpha
beta
gamma
delta

或者我们可以假设相反的情况，即文件最初包含所有四行，因此在A

delta

中删除，在B

beta

中删除：

alpha
gamma

或者我们可以说分支B实际上从未接触过该文件，因此应该忽略其状态，并保留A的内容。如果分支A从未接触过该文件，则同样的情况也可能相反

---

正如您所看到的，拥有这些分支的基础，以及这些分支的实际差异对于决定合并应该如何解决有很大帮助。毕竟，我们希望使用分支独立于其他分支（使用其他独立开发线）开发东西只需在中合并所有更改，而无需再次执行合并过程中的所有工作。

。这就是我感到困惑的地方。如果A有完整的快照，B有完整的快照，我们可以比较A和B，我们可以合并它，所以我们需要公共基础C@vicky我用一个例子来扩展我的答案，我想我明白了。用一个共同的祖先文件检查另外两个文件，如果在一个文件中发现任何更改，那么使用该更改，如果两个文件都发生了更改，则会导致冲突。我说的对吗？Git实际上更聪明一些，并且会根据每行进行决定。因此，如果在文件的不同部分添加代码（例如，每个分支向类添加一个方法），则不会出现冲突，但Git会自动确保合并版本中存在这两个代码：）