1.1 開始 - 關於版本控制

很多人作版本控制的方法是把檔案複製到另一個目錄（如果他們夠聰明的話，他們還會幫資料夾加上時間）。 這種做法很常見，因為這樣做很簡單，但是卻也非常容易產生離譜的錯誤。 這種做法非常容易搞混資料夾，意外寫錯檔案或複製覆蓋到不想要的檔案。

為了解決這個問題，程式設計師很久以前就開發了很多種本機版本控制系統，大多都是採用某種簡單的資料庫來紀錄檔案的所有變更記錄。

其中最流行的一種叫做 RCS，至今許多電腦上都還可以找到他的蹤影。 甚至在流行的 Mac OS X 系統中，只要安裝了開發者工具包以後，你就會有 rcs 的指令可以使用。 RCS 的工作原理是在硬碟上保存一堆特殊格式的補丁集合（patch set，即檔案從一個版本變更到另一個版本所需資訊）；通過套用任意的補丁，便可以重新產生出每個版本的檔案內容。

接下來人們又遇到了重大問題，就是如何和其他電腦上的開發者協同合作？ 為了解決這個問題，於是集中化的版本控制系統應運而生。 這類系統（如：CVS、Subversion 和 Perforce），都有一個伺服器來管理所有版本的檔案，而許多用戶端會連到這台伺服器取出檔案來使用。 多年以來，這儼然成為版本控制系統的標準做法。

相對於本機版本控制系統，這種做法帶來了許多好處。 舉例來說，每個人都可以一定程度的知道專案中的其他人正在做些什麼。 管理員也可以輕鬆掌控每個開發者的權限；而且比每個用戶端只用本機的版本控制系統好管理很多。

然而，集中化的版本控制系統也有一些嚴重的缺點。 最嚴重的當然是中央伺服器如果發生故障的時候。 如果當機一小時，那麼這個小時之中，沒有人可以提交更新，也就無法協同合作。 如果中心版本庫的硬碟發生損壞，又沒有做適當的備份，那麼你就絕對會遺失所有資料——包括專案的全部變更歷史，只會剩下用戶端各自機器上保留的單獨快照。 本機版本控制系統也存在類似的問題——只要你的專案歷史都放在同一個地方，就有遺失所有資料的風險。

於是分散式版本控制系統（Distributed Version Control Systems，簡稱 DVCSs）就此登上舞台。 在 DVCS 系統（如 Git、Mercurial、Bazaar 和 Darcs）中，用戶端並不只取出最新的檔案快照；還把整個倉儲做個鏡像。 假設有任何一個協同合作的伺服器故障，事後都可以用任何一個用戶端的鏡像來還原。 因為每個地方都有完整的資料備份。

除此之外，許多這類的系統都可以很好的和許多遠端倉儲互動，所以你可以和不同群組的人使用不同的方式，在同一個專案內協同合作。 你可以根據需要設定許多工作流程（如：階層式模型），這是在集中式的版本控制系統中是無法實現的。