這一章基本上沒什么大營養，不愿意看的可以略過。。。

關于版本控制

1. 本地版本控制

   沒什么可說的，最原始的方式。自己根據習慣標記一些日期等

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

2. 集中化的版本控制

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

   事分兩面，有好有壞。這么做最顯而易見的缺點是中央服務器的單點故障。如果宕機一小時，那么在這一小時內，誰都無法提交更新，也就無法協同工作。要是中央服務器的磁盤發生故障，碰巧沒做備份，或者備份不夠及時，就會有丟失數據的風險。最壞的情況是徹底丟失整個項目的所有歷史更改記錄，而被客戶端偶然提取出來的保存在本地的某些快照數據就成了恢復數據的希望。但這樣的話依然是個問題，你不能保證所有的數據都已經有人事先完整提取出來過。本地版本控制系統也存在類似問題，只要整個項目的歷史記錄被保存在單一位置，就有丟失所有歷史更新記錄的風險。

3. 分布式版本控制系統

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

Git 簡史

1. 同生活中的許多偉大事件一樣，Git 誕生于一個極富紛爭大舉創新的年代。Linux 內核開源項目有著為數眾廣的參與者。絕大多數的 Linux 內核維護工作都花在了提交補丁和保存歸檔的繁瑣事務上（1991－2002年間）。到 2002 年，整個項目組開始啟用分布式版本控制系統 BitKeeper 來管理和維護代碼。

   到了 2005 年，開發 BitKeeper 的商業公司同 Linux 內核開源社區的合作關系結束，他們收回了免費使用 BitKeeper 的權力。這就迫使 Linux 開源社區（特別是 Linux 的締造者 Linus Torvalds ）不得不吸取教訓，只有開發一套屬于自己的版本控制系統才不至于重蹈覆轍。他們對新的系統制訂了若干目標：

   • 速度
   • 簡單的設計
   • 對非線性開發模式的強力支持（允許上千個并行開發的分支）
   • 完全分布式
   • 有能力高效管理類似 Linux 內核一樣的超大規模項目（速度和數據量）

   自誕生于 2005 年以來，Git 日臻成熟完善，在高度易用的同時，仍然保留著初期設定的目標。它的速度飛快，極其適合管理大項目，它還有著令人難以置信的非線性分支管理系統（見第三章），可以應付各種復雜的項目開發需求。