分佈式修訂控制系統的分散行爲如何工作？

Question

我想知道分散式DVCS的工作如何？如果沒有中央服務器，開發人員機器如何知道和同步存儲庫與其他開發人員機器的存儲庫。這些更改如何合併？因爲缺乏中央服務器似乎對我來說系統可能會導致每個存儲庫有不同的版本號。以及如何處理衝突解決方案？

Answer 1

我偏愛的Git，但我相信理論適用於大多數其他系統...

分散式VCS旨在通過在每次提交中保留一個指向先前提交的指針來處理分支和合並作爲其DNA的一部分，因此任何更改都可以追溯到共同的祖先。

版本「數字」本身不用於引用提交。顯然，如果是這種情況，將會有多個序列...在Git的情況下，唯一標識任何提交的指針「key」是SHA1哈希。使整個安排順序唯一的是指向每個提交的父代的指針圖。

在實踐中，開發者提交他們的工作，以自己的本地副本中，當它的時間與他人分享，他們在三個方面這樣做：

• 向其他開發者直接拉動變化從他們
• 直接推到其他開發人員的副本
• 變更推到中央位置，其他人可以從

拉這些都是真正在T同樣的事情他結束了，因爲它只是歸結爲差異。在第三種情況下，中央位置僅僅作爲代理 - 沒有它，同樣的事情就可以實現。

系統可以像您選擇的那樣集中或分散。由於實際原因，大多數項目都具有一定數量的集中化，但任何時候叉都可以成爲新的中央存儲庫，或者開發人員可以選擇自己之間交易代碼。

當提交被提取併合併到您自己的副本中時，它們將應用於您與上游存儲庫共享的任何共同祖先之上。如果發生衝突，合併進程將在發生衝突的提交步驟處暫停，並要求您在繼續將其餘提交應用於其上之前解決該問題。 （標準的統一差異標記用於標記衝突。）

大多數合併是自動發生的，但是當發生衝突時，通常很難解決。好處是，最終不會出現跨越多個提交的衝突的球：它更容易解決，因爲它在歷史中間暫停，並允許您以更小，邏輯的塊處理它。

Answer 2

去年Scott Chacon從RailsConf的介紹非常棒。這是我見過的最好的計劃外信息會談之一。我會聽從他（具體而言，你的問題，遠程工作流程的一部分圍繞18分鐘開始到它）：

RailsConf Git Talk