版本控制

本章關于開始學習 Git。這篇文章將從介紹有關版本控制工具的一些背景知識開始，然后講解如何在系統運行 Git，最后是關于如何設置 Git 開始工作。 通過本章的學習，了解為什么 Git 這么流行，為什么要使用 Git 以及應該如何設置以便使用 Git。

⒈ 關于版本控制

什么是“版本控制”?為什么要關心它呢? 版本控制是一種記錄一個或若干文件內容變化，以便將來查閱特定版本修訂情況的系統。在本書所展示的例子中，我們對保存著軟件源代碼的文件作版本控制，但實際上，可以對任何類型的文件進行版本控制。

如果你是位圖形或網頁設計師，可能會需要保存某一幅圖片或頁面布局文件的所有修訂版本(這或許是你非?？释麚碛械墓δ?，采用版本控制系統(VCS)是個明智的選擇。 有了它就可以將某個文件回溯到之前的狀態，甚至將整個項目都回退到過去某個時間點的狀態，可以比較文件的變化細節，查出最后是誰修改了哪個地方，從而找出導致怪異問題出現的原因，又是誰在何時報告了某個功能缺陷等等。 使用版本控制系統通常還意味著，就算你亂來一氣把整個項目中的文件改的改，刪的刪了，這也沒有關系，你也照樣可以很容易地就恢復到原先的樣子。但額外增加的工作量卻微乎其微。

⒉ 本地版本控制系統

許多人習慣用復制整個項目目錄的方式來保存不同的版本，或許還會改名加上備份時間以示區別。 這么做唯一的好處就是簡單，但是特別容易犯錯。 有時候會混淆所在的工作目錄，一不小心會寫錯文件或者覆蓋意想外的文件。

為了解決這個問題，人們很久以前就開發了許多種本地版本控制系統，大多都是采用某種簡單的數據庫來記錄文件的歷次更新差異。

其中最流行的一種叫做 RCS，現今許多計算機系統上都還看得到它的蹤影。 甚至在流行的 Mac OS X 系統上安裝了開發者工具包之后，也可以使用 rcs 命令。 它的工作原理是在硬盤上保存補丁集(補丁是指文件修訂前后的變化);通過應用所有的補丁，可以重新計算出各個版本的文件內容。

⒊ 集中化的版本控制系統

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

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

事分兩面，有好有壞。 這么做最顯而易見的缺點是中央服務器的單點故障。 如果宕機一小時，那么在這一小時內，誰都無法提交更新，也就無法協同工作。 如果中心數據庫所在的磁盤發生損壞，又沒有做恰當備份，毫無疑問您將丟失所有數據——包括項目的整個變更歷史，只剩下人們在各自機器上保留的單獨快照。本地版本控制系統也存在類似問題，只要整個項目的歷史記錄被保存在單一位置，就有丟失所有歷史更新記錄的風險。

⒋ 分布式版本控制系統

于是分布式版本控制系統(Distributed Version Control System，簡稱 DVCS)面世了。 在這類系統中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客戶端并不只提取最新版本的文件快照，而是把代碼倉庫完整地鏡像下來。 這么一來，任何一處協同工作用的服務器發生故障，事后都可以用任何一個鏡像出來的本地倉庫恢復。 因為每一次的克隆操作，實際上都是一次對代碼倉庫的完整備份。如下圖所示：

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