Git詳解之一：Git起步

起步

本章介紹開始使用 Git 前的相關知識。我們會先了解一些版本控制工具的歷史背景，然後試著讓 Git 在你的系統上跑起來，直到最後配置好，可以正常開始開發工作。讀完本章，你就會明白為什麼 Git 會如此流行，為什麼你應該立即開始使用它。（查看Git詳解系列的全部文章）

1.1 關於版本控制

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

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

本地版本控制系統

許多人習慣用複製整個項目目錄的方式來保存不同的版本，或許還會改名加上備份時間以示區別。這麼做唯一的好處就是簡單。不過壞處也不少：有時候會混淆所在的工作目錄，一旦弄錯文件丟了數據就沒法撤銷恢復。

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

圖 1-1. 本地版本控制系統

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

集中化的版本控制系統

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

圖 1-2. 集中化的版本控制系統

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

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

分散式版本控制系統

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

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

1.2 Git 簡史

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

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

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

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

1.3 Git 基礎

那麼，簡單地說，Git 究竟是怎樣的一個系統呢？請注意，接下來的內容非常重要，若是理解了 Git 的思想和基本工作原理，用起來就會知其所以然，遊刃有餘。在開始學習 Git 的時候，請不要嘗試把各種概念和其他版本控制系統（諸如 Subversion 和 Perforce 等）相比擬，否則容易混淆每個操作的實際意義。Git 在保存和處理各種信息的時候，雖然操作起來的命令形式非常相近，但它與其他版本控制系統的做法頗為不同。理解這些差異將有助於你準確地使用 Git 提供的各種工具。

直接記錄快照，而非差異比較

Git 和其他版本控制系統的主要差別在於，Git 只關心文件數據的整體是否發生變化，而大多數其他系統則只關心文件內容的具體差異。這類系統 （CVS，Subversion，Perforce，Bazaar 等等）每次記錄有哪些文件作了更新，以及都更新了哪些行的什麼內容，請看圖 1-4。

Git 並不保存這些前後變化的差異數據。實際上，Git 更像是把變化的文件作快照后，記錄在一個微型的文件系統中。每次提交更新時，它會縱覽一遍所有文件的指紋信息並對文件作一快照，然後保存一個指向這次快照 的索引。為提高性能，若文件沒有變化，Git 不會再次保存，而只對上次保存的快照作一鏈接。Git 的工作方式就像圖 1-5 所示。

這是 Git 同其他系統的重要區別。它完全顛覆了傳統版本控制的套路，並對各個環節的實現方式作了新的設計。Git 更像是個小型的文件系統，但它同時還提供了許多以此為基礎的超強工具，而不只是一個簡單的 VCS。稍後在第三章討論 Git 分支管理的時候，我們會再看看這樣的設計究竟會帶來哪些好處。

近乎所有操作都是本地執行

在 Git 中的絕大多數操作都只需要訪問本地文件和資源，不用連網。但如果用 CVCS 的話，差不多所有操作都需要連接網路。因為 Git 在本地磁碟上就保存著所有當前項目的歷史更新，所以處理起來速度飛快。

舉個例子，如果要瀏覽項目的歷史更新摘要，Git 不用跑到外面的伺服器上去取數據回來，而直接從本地資料庫讀取后展示給你看。所以任何時候你都可以馬上翻閱，無需等待。如果想要看當前版本的文件和一個月 前的版本之間有何差異，Git 會取出一個月前的快照和當前文件作一次差異運算，而不用請求遠程伺服器來做這件事，或是把老版本的文件拉到本地來作比較。

用 CVCS 的話，沒有網路或者斷開 VPN 你就無法做任何事情。但用 Git 的話，就算你在飛機或者火車上，都可以非常愉快地頻繁提交更新，等到了有網路的時候再上傳到遠程倉庫。同樣，在回家的路上，不用連接 VPN 你也可以繼續工作。換作其他版本控制系統，這麼做幾乎不可能，抑或非常麻煩。比如 Perforce，如果不連到伺服器，幾乎什麼都做不了（譯註：默認無法發出命令

開始編輯文件，因為 Perforce 需要聯網通知系統聲明該文件正在被誰修訂。但實際上手工修改文件許可權可以繞過這個限制，只是完成後還是無法提交更新。）；如果是 Subversion 或 CVS，雖然可以編輯文件，但無法提交更新，因為資料庫在網路上。看上去好像這些都不是什麼大問題，但實際體驗過之後，你就會驚喜地發現，這其實是會帶來很大不同的。

時刻保持數據完整性

在保存到 Git 之前，所有數據都要進行內容的校驗和（checksum）計算，並將此結果作為數據的唯一標識和索引。換句話說，不可能在你修改了文件或目錄之後，Git 一無所知。這項特性作為 Git 的設計哲學，建在整體架構的最底層。所以如果文件在傳輸時變得不完整，或者磁碟損壞導致文件數據缺失，Git 都能立即察覺。

Git 使用 SHA-1 演算法計算數據的校驗和，通過對文件的內容或目錄的結構計算出一個 SHA-1 哈希值，作為指紋字元串。該字串由 40 個十六進位字元（0-9 及 a-f）組成，看起來就像是：