Pro Git 1.1 關於版本控制

出自DILA Wiki

什麼是版本控制?我真的需要嗎?版本控制是一種記錄若干檔案內容變化,以便將來查閱特定版本修訂情況的系統。在本書所展示的例子中,我們僅對保存著軟體原始程式碼的文字檔作版本控制管理,而實際上,你可以對任何類型的檔進行版本控制。

如果你是位元圖形或網頁設計師,可能會需要保存某一幅圖片或頁面配置檔的所有修訂版本。採用版本控制系統(VCS)是個明智的選擇。有了它你就可以將某個檔回溯到之前的狀態,甚至將整個專案都回退到過去某個時間點的狀態。你可以比較檔的變化細節,查出是誰最後修改了什麼地方從而造成某些怪異問題,又是誰在何時報告了某個功能缺陷,等等。使用版本控制系統通常還意味著,就算你胡來搞砸了整個專案,把檔改的改,刪的刪,你也可以輕鬆恢復到原先的樣子。而由此額外增加的工作量卻微乎其微。

本地版本控制系统

許多人習慣用複製整個專案目錄的方式來保存不同的版本,或許還會改名加上備份時間以示區別。這麼做唯一的好處就是簡單,不過壞處卻不少:有時候會混淆所在的工作目錄,弄錯了檔丟了資料就沒了後退的路。

為了解決這個問題,人們很久以前就開發了許多種本地版本控制系統,大多都是採用某種簡單的資料庫來記錄檔的歷次更新差異(見圖 1-1)。

Pro-git-1-1.png 圖 1-1. 本地版本控制系統

其中最流行的一種叫做 rcs,現今許多電腦系統上都還看得到它的蹤影。甚至在流行的 Mac OS X 系統上安裝了開發者工具包之後,也可以使用 rcs 命令。它的工作原理基本上就是保存並管理文件補丁(patch)。檔補丁是一種特定格式的文字檔,記錄著對應檔修訂前後的內容變化。所以,根據每次修訂後的補丁,rcs 可以通過不斷打補丁,計算出各個版本的檔內容。

集中化的版本控制系统

接下來人們又遇到一個問題,如何讓在不同系統上的開發者協同工作?於是,集中化的版本控制系統( Centralized Version Control Systems,簡稱 CVCS )應運而生。這類系統,諸如 CVS,Subversion 以及 Perforce 等,都有一個單一的集中管理的伺服器,保存所有檔的修訂版本,而協同工作的人們都通過用戶端連到這台伺服器,取出最新的檔或者提交更新。多年以來,這已成為版本控制系統的標準做法(見圖 1-2)。

Pro-git-1-2.png

這種做法帶來了許多好處,特別是相較於老式的本地 VCS 來說。現在,每個人都可以一定程度上看到項目中的其他人正在做些什麼。而管理員也可以輕鬆掌控每個開發者的許可權,並且管理一個 CVCS 要遠比在各個用戶端上維護本地資料庫輕鬆容易得多。

事分兩面,有好有壞。這麼做最顯而易見的缺點中央伺服器的單點故障。若是宕機一小時,那麼在這一小時內,誰都無法提交更新,也就無法協同工作。如果中央伺服器的磁片發生故障,並且沒做過備份或者備份得不夠及時的話,還會有丟失資料的風險。最壞的情況是徹底丟失整個專案的所有歷史更改記錄,被用戶端提取出來的某些快照資料除外,但這樣的話依然是個問題,你不能保證所有的資料都已經有人提取出來。本地版本控制系統也存在類似問題,只要整個專案的歷史記錄被保存在單一位置,就有丟失所有歷史更新資訊的風險。

分散式版本控制系統

於是分散式版本控制系統( Distributed Version Control System,簡稱 DVCS )面世了。在這類系統中,諸如 Git,Mercurial,Bazaar 還有 Darcs 等,用戶端並不只提取最新版本的檔快照,而是把原始的代碼倉庫完整地鏡像下來。這麼一來,任何一處協同工作用的伺服器發生故障,事後都可以用任何一個鏡像出來的本地倉庫恢復。因為每一次的提取操作,實際上都是一次對代碼倉庫的完整備份(見圖 1-3)。

Pro-git-1-3.png 圖 1-3. 分散式版本控制系統

更進一步,許多這類系統都可以指定和若干不同的遠端代碼倉庫進行交互。籍此,你就可以在同一個專案中,分別和不同工作小組的人相互協作。你可以根據需要設定不同的協作流程,比方說層次模型式的工作流,這在以前的集中式系統中是無法實現的。