上一節說完了VCS，在這裡來說說分散式版本控制系統DVCS

什麼是分散式版本控制系統（DVCS）

分散式 VCS （Distributed VCS / DVCS）和中央式的區別在於，分散式 VCS 除了中央倉庫之外，還有本地倉庫：團隊中每一個成員的機器上都有一份本地倉庫，這個倉庫裡包含了所有的版本歷史，或者換句話說，每個人在自己的機器上就可以提交程式碼、檢視歷史，而無需聯網和中央倉庫互動——當然，取而代之的，你需要和本地倉庫互動。

中央式 VCS 的中央倉庫有兩個主要功能：儲存版本歷史、同步團隊程式碼。而在分散式 VCS 中，儲存版本歷史的工作轉交到了每個團隊成員的本地倉庫中，中央倉庫就只剩下了同步團隊程式碼這一個主要任務。它的中央倉庫依然也儲存了歷史版本，但這份歷史版本更多的是作為團隊間的同步中轉站。

工作模型

依然以三人團隊為例，分散式 VCS 的工作模型大致是這樣：

1. 首先，你作為主工程師，獨立搭建了專案架構，並把這些程式碼提交到了本地倉庫；
2. 然後，你在伺服器上建立了一箇中央倉庫，並把 1 中的提交從本地倉庫推送到了伺服器的中央倉庫；
3. 其他同事把中央倉庫的所有內容克隆到本地，擁有了各自的本地倉庫，從此刻開始，你們三人開始並行開發；
4. 在之後的開發過程中，你們三人總是每人獨立負責開發一個功能，在這個功能開發過程中，一個人會把它的每一步改動提交到本地倉庫。注意：由於本地提交無需立即上傳到中央倉庫，所以每一步提交不必是一個完整功能，而可以是功能中的一個步驟或塊。
5. 在一個人把某個功能開發完成之後，他就可以把這個功能相關的所有提交從本地倉庫推送到中央倉庫；
6. 每次當有人把新的提交推送到中央倉庫的時候，另外兩個人就可以選擇把這些提交同步到自己的機器上，並把它們和自己的原生代碼合併。
   

可以看出，這個工作模型和上一節講的「中央式 VCS 的工作模型」很相似，只是把程式碼的提交和上傳過程拆開了。

另外，和上節講的中央式 VCS 工作模型一樣，這個也只是分散式 VCS 的一個最基本的工作模型，實際的開發工作會比這個麻煩和複雜。但這是個核心模型。

優點和缺點

分散式VCS的優點：

1. 大多數的操作可在本地進行，所以速度很快，而且由於無需聯網，所以即使不在公司甚至沒有聯網，都可以提交程式碼，檢視歷史，從而極大減小了開發者的網路條件和物理位置的限制。
2. 由於可以提交到本地，所以可以分佈提交程式碼，把程式碼提交做得更細，而不是一個提交包含很多程式碼，難以review也難以回溯。

分散式VCS的缺點：

1. 由於每一個機器都有完整的本地倉庫，所以初次獲取專案（Git術語：clone）的時候會比較耗時；
2. 由於每個機器都有完整的本地倉庫，所以本地佔用的儲存比中央式VCS要高。

實際開發中：
對於一般的程式專案而言，由於專案的大多數內容都是文字形式的程式碼，所以工程的體積都並不是很大，再加上文字內容自身的特點，VCS 可以利用演算法來把倉庫的體積極大地壓縮。這就導致，在實際中，Git 等分散式 VCS 的倉庫體積並不大，初次獲取專案的耗時和本地倉庫的儲存佔用都很小。所以對於大多數的程式專案而言，分散式 VCS 「尺寸大、初次下載慢」的問題其實並不嚴重。

不過也有一些例外，比如遊戲開發。遊戲的開發中有大量的大尺寸資料和媒體檔案，並且這些檔案的格式也不容易壓縮尺寸，如果用分散式 VCS 會導致倉庫的體積非常龐大。所以一些大型遊戲的開發會選擇中央式的 VCS 來管理程式碼。