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