TA貢獻(xiàn)1898條經(jīng)驗(yàn) 獲得超8個(gè)贊
Git不會阻止合并中的沖突，但是即使它們不共享任何父祖先，也可以協(xié)調(diào)歷史記錄。
（通過嫁接文件（.git/info/grafts），它是提交的列表，每行一個(gè)提交，后跟其父級，您可以出于“和解”的目的進(jìn)行修改。）
如此強(qiáng)大。
但是要真正了解“如何考慮合并”，您可以從Linus自己開始，然后意識到這個(gè)問題與“算法”并沒有太大關(guān)系：
萊納斯（Linus）：我個(gè)人來說，我想擁有一種非常可重復(fù)且非巧妙的東西。我了解或告訴我它做不到的事情。
坦率地說，合并單個(gè)文件的歷史記錄而不考慮其他所有文件的歷史記錄會使我“很煩”。
合并的重要部分不是如何處理沖突（如果沖突很有趣，則無論如何都要由人來驗(yàn)證），而是應(yīng)該將歷史融合在一起，以便為將來的合并奠定新的堅(jiān)實(shí)基礎(chǔ)。
換句話說，重要的部分是瑣碎的部分：給父母命名，并跟蹤他們的關(guān)系。不是沖突。
似乎有99％的SCM人似乎認(rèn)為解決方案是對內(nèi)容合并更加聰明。這完全錯(cuò)了重點(diǎn)。
因此Wincent Colaiuta補(bǔ)充說（我的重點(diǎn)是）：
不需要花哨的元數(shù)據(jù)，重命名跟蹤等。
您唯一需要存儲的是每次更改前后的樹狀態(tài)。
什么文件被重命名？哪些被復(fù)制？哪些被刪除？添加了哪些行？哪些被刪除？其中哪些行進(jìn)行了更改？哪些文本是從一個(gè)文件復(fù)制到另一個(gè)文件的？
您不必關(guān)心這些問題中的任何一個(gè)，當(dāng)然也不必保留特殊的跟蹤數(shù)據(jù)來幫助您回答它們：對樹的所有更改（添加，刪除，重命名，編輯等）都是隱式的編碼在樹的兩種狀態(tài)之間的增量中 ; 你只跟蹤什么內(nèi)容。
絕對可以（并且應(yīng)該）推斷一切。
Git打破了常規(guī)，因?yàn)樗豢紤]內(nèi)容而不是文件。
它不跟蹤重命名，而是跟蹤內(nèi)容。它是在整個(gè)樹級別上執(zhí)行的。
這與大多數(shù)版本控制系統(tǒng)完全不同。
嘗試存儲每個(gè)文件的歷史記錄不會麻煩。而是將歷史記錄存儲在樹級別。
執(zhí)行差異時(shí)，您要比較的是兩棵樹，而不是兩個(gè)文件。
另一個(gè)根本上明智的設(shè)計(jì)決策是Git如何合并。
合并算法很聰明，但不要試圖太聰明。明確的決定是自動(dòng)做出的，但是如果有疑問，則由用戶決定。
這是應(yīng)該的方式。您不希望機(jī)器為您做出這些決定。您永遠(yuǎn)不會想要它。
這是Git合并方法的基本見解：雖然其他所有版本控制系統(tǒng)都在試圖變得更智能，但Git卻自稱為“愚蠢的內(nèi)容管理器”，并且這樣做更好。
TA貢獻(xiàn)1895條經(jīng)驗(yàn) 獲得超7個(gè)贊
上面的答案都是正確的，但我認(rèn)為它們對我來說錯(cuò)過了git輕松合并的中心點(diǎn)。SVN合并要求您保持跟蹤并記住已合并的內(nèi)容，這是一個(gè)巨大的PITA。從他們的文檔：
svn merge -r 23:30 file:///tmp/repos/trunk/vendors
現(xiàn)在這不是殺手er，但是如果您忘記了它是23-30包含式還是23-30包含式，或者您是否已經(jīng)合并了其中一些提交，就變得無所適從，必須找出答案以避免重復(fù)或丟失提交。如果您分支了，上帝會幫助您。
有了git，它只是git merge，而這一切都是無縫進(jìn)行的，即使您選擇了幾次提交或完成了許多夢幻般的git-land事情。
舉報(bào)