版本管理就是管理更新的曆史記錄。它為我們提供了一些在軟體開發過程中必不可少的功能，例如記錄一款軟體添加或更改源代碼的過程，復原到特定階段，恢複誤删除的檔案等。
在Git出現以前，人們普遍采用Subversion等集中型版本管理系統，而現在Git已經成為了主流。由于GitHub的普及，想必世界上使用Git的人會越來越多。是以要學習版本管理的各位，建議您選擇Git。
●集中型與分散型
剛才我們提到版本管理系統分為Subversion這類集中型的與Git這類分散型的，下面就為各位簡單說明一下二者的不同點。
集中型
以Subversion為代表的集中型，會如圖2.1所示将倉庫集中存放在伺服器之中，是以隻存在一個倉庫。這就是為什麼這種版本管理系統會被稱作集中型。
集中型将所有資料集中存放在伺服器當中，有便于管理的優點
。但是一旦開發者所處的環境不能連接配接伺服器，就無法擷取最新的源代碼，開發也就幾乎無法進行。伺服器當機時也是同樣的道理，而且萬一伺服器故障導緻資料消失，恐怕開發者就再也見不到最新的源代碼了。
分散型
圖2.2是以Git為代表的分散型的示意圖。如圖中所示，GitHub将倉庫Fork給了每一個使用者。Fork就是将GitHub的某個特定倉庫複制到自己的賬戶下。Fork出的倉庫與原倉庫是兩個不同的倉庫，開發者可以随意編輯。
如圖所示，分散型擁有多個倉庫，相對而言稍顯複雜。不過，
由于本地的開發環境中就有倉庫，是以開發者不必連接配接遠端倉庫就可以進行開發
。
圖中隻顯示了一般的使用流程。實際上，所有倉庫之間都可以進行push和pull。即便不通過GitHub，開發者A也可以直接向開發者B的倉庫進行push或pull。是以在使用前如果不事先制定規範，初學者往往會搞不清最新的源代碼儲存在哪裡，導緻開發失去控制。
●集中型與分散型哪個更好
要說集中型與分散型哪個更好，其實雙方都各有優缺點，需要看具體情況而定。不過，随着Git與GitHub的普及，今後使用分散型的開發者将會占絕大多數。隻要規則制定得當，分散型同樣能像集中型那樣進行管理。
有些人在學習版本管理的相關知識時，認為該從相對簡單的集中型入手，再循序漸進學習分散型。但筆者認為，今後用到集中型的機會很少，是以不必特地繞這個彎路。
同樣，建議想給團隊導入版本管理系統的讀者選擇GitHub與Git。如果軟體開發進行到一半再從集中型轉為分散型，不但需要支付高額的費用，還要讓開發者花費大量的精力與金錢去重新學習。考慮到今後的各種機遇與挑戰，從一開始就選擇分散型，必定是各位成功路上的關鍵一步。
隻要腦中掌握了多個倉庫并存的概念，學習分散型并不是什麼難事。而且對于剛剛接觸這方面知識的人來說，由于沒有先入為主的幹擾，應該很容易接受這一概念。