為什么在git中需要三向合並所需的共同祖先？

Question

我是git的新手，我明白什么是快進合並[如果兩個分支是線性的只是將指針移動到分支]但是當它來到3路合並時它會讓我困惑，因為為什么3路合並需要共同的祖先創建一個新的提交為什么不能采取兩個分支[我想要合並到的分支（例如：master）和一些想要合並的分支（例如：immediatefix）]並比較它們只是做一個合並..為什么呢你想要共同的祖先。而且還要為了我們需要共同的祖先而改變...

Answer 1

這很簡單，歸結為Git如何提交。 與其他VCS不同，Git存儲整個工作目錄的完整快照。 因此，在查看單個提交時，您只能看到提交內容的確切狀態。

像Subversion這樣的其他VCS通常存儲差異。 因此，修訂存儲為先前狀態和當前狀態之間的差異。 因此，在合並時，您只需查看單個修訂版即可查看發生的情況，並將其應用於其他地方。

另一方面，Git沒有那種隨時可用的差異。 為了能夠查看提交中發生的事情，需要將內容與父提交進行比較。 只有這樣它才能產生差異並將其應用於其他地方。 因此對於具有共同基數C兩個分支A和B ，Git所做的是查看A和C以及B和C之間的差異。 然后它知道每個分支中到底發生了什么，並且可以嘗試應用所有更改。 這樣做的好處是可以看到整個變化范圍，所以如果你暫時改變一個分支中的某些東西但是稍后解除了它，那么在合並時它將不會顯示完全不同。 這通常會減少沖突。

同樣適用於rebase，除了它實際上是以它的名義。 將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從未觸及文件，則反向適用。

正如您所看到的，擁有這些分支的基礎，因此分支的實際差異有助於決定如何解決合並。 畢竟，我們希望使用分支來獨立於其他分支（使用其他獨立開發線）開發內容，並且只需合並所有更改，而無需在合並期間完成所有工作。