# 起航 本章介紹開始使用?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-3.?分布式版本控制系統 更進一步，許多這類系統都可以指定和若干不同的遠端代碼倉庫進行交互。籍此，你就可以在同一個項目中，分別和不同工作小組的人相互協作。你可以根據需要設定不同的協作流程，比如層次模型式的工作流，而這在以前的集中式系統中是無法實現的。 ## 1.2?Git?簡史 同生活中的許多偉大事件一樣，Git?誕生于一個極富紛爭大舉創新的年代。Linux?內核開源項目有著為數眾廣的參與者。絕大多數的?Linux?內核維護工作都花在了提交補丁和保存歸檔的繁瑣事務上（1991－2002年間）。到?2002?年，整個項目組開始啟用分布式版本控制系統?BitKeeper?來管理和維護代碼。 到了?2005?年，開發?BitKeeper?的商業公司同?Linux?內核開源社區的合作關系結束，他們收回了免費使用?BitKeeper?的權力。這就迫使?Linux?開源社區（特別是?Linux?的締造者?Linus?Torvalds?）不得不吸取教訓，只有開發一套屬于自己的版本控制系統才不至于重蹈覆轍。他們對新的系統制訂了若干目標： 2?速度? 2?簡單的設計? 2?對非線性開發模式的強力支持（允許上千個并行開發的分支）? 2?完全分布式? 2?有能力高效管理類似?Linux?內核一樣的超大規模項目（速度和數據量） 自誕生于?2005?年以來，Git?日臻成熟完善，在高度易用的同時，仍然保留著初期設定的目標。它的速度飛快，極其適合管理大項目，它還有著令人難以置信的非線性分支管理系統（見第三章），可以應付各種復雜的項目開發需求。 ## 1.3?Git?基礎 那么，簡單地說，Git?究竟是怎樣的一個系統呢？請注意，接下來的內容非常重要，若是理解了?Git?的思想和基本工作原理，用起來就會知其所以然，游刃有余。在開始學習?Git?的時候，請不要嘗試把各種概念和其他版本控制系統（諸如?Subversion?和?Perforce?等）相比擬，否則容易混淆每個操作的實際意義。Git?在保存和處理各種信息的時候，雖然操作起來的命令形式非常相近，但它與其他版本控制系統的做法頗為不同。理解這些差異將有助于你準確地使用?Git?提供的各種工具。 ### 直接記錄快照，而非差異比較 Git?和其他版本控制系統的主要差別在于，Git?只關心文件數據的整體是否發生變化，而大多數其他系統則只關心文件內容的具體差異。這類系統?（CVS，Subversion，Perforce，Bazaar?等等）每次記錄有哪些文件作了更新，以及都更新了哪些行的什么內容，請看圖?1-4。  圖?1-4.?其他系統在每個版本中記錄著各個文件的具體差異 Git?并不保存這些前后變化的差異數據。實際上，Git?更像是把變化的文件作快照后，記錄在一個微型的文件系統中。每次提交更新時，它會縱覽一遍所有文件的指紋信息并對文件作一快照，然后保存一個指向這次快照?的索引。為提高性能，若文件沒有變化，Git?不會再次保存，而只對上次保存的快照作一鏈接。Git?的工作方式就像圖?1-5?所示。  圖?1-5.?Git?保存每次更新時的文件快照 這是?Git?同其他系統的重要區別。它完全顛覆了傳統版本控制的套路，并對各個環節的實現方式作了新的設計。Git?更像是個小型的文件系統，但它同時還提供了許多以此為基礎的超強工具，而不只是一個簡單的?VCS。稍后在第三章討論?Git?分支管理的時候，我們會再看看這樣的設計究竟會帶來哪些好處。 ### 近乎所有操作都是本地執行 在?Git?中的絕大多數操作都只需要訪問本地文件和資源，不用連網。但如果用?CVCS?的話，差不多所有操作都需要連接網絡。因為?Git?在本地磁盤上就保存著所有當前項目的歷史更新，所以處理起來速度飛快。 舉個例子，如果要瀏覽項目的歷史更新摘要，Git?不用跑到外面的服務器上去取數據回來，而直接從本地數據庫讀取后展示給你看。所以任何時候你都可以馬上翻閱，無需等待。如果想要看當前版本的文件和一個月?前的版本之間有何差異，Git?會取出一個月前的快照和當前文件作一次差異運算，而不用請求遠程服務器來做這件事，或是把老版本的文件拉到本地來作比較。 用?CVCS?的話，沒有網絡或者斷開?VPN?你就無法做任何事情。但用?Git?的話，就算你在飛機或者火車上，都可以非常愉快地頻繁提交更新，等到了有網絡的時候再上傳到遠程倉庫。同樣，在回家的路上，不用連接?VPN?你也可以繼續工作。換作其他版本控制系統，這么做幾乎不可能，抑或非常麻煩。比如?Perforce，如果不連到服務器，幾乎什么都做不了（譯注：默認無法發出命令p4?edit?file?開始編輯文件，因為?Perforce?需要聯網通知系統聲明該文件正在被誰修訂。但實際上手工修改文件權限可以繞過這個限制，只是完成后還是無法提交更新。）；如果是?Subversion?或?CVS，雖然可以編輯文件，但無法提交更新，因為數據庫在網絡上。看上去好像這些都不是什么大問題，但實際體驗過之后，你就會驚喜地發現，這其實是會帶來很大不同的。 ### 時刻保持數據完整性 在保存到?Git?之前，所有數據都要進行內容的校驗和（checksum）計算，并將此結果作為數據的唯一標識和索引。換句話說，不可能在你修改了文件或目錄之后，Git?一無所知。這項特性作為?Git?的設計哲學，建在整體架構的最底層。所以如果文件在傳輸時變得不完整，或者磁盤損壞導致文件數據缺失，Git?都能立即察覺。 Git?使用?SHA-1?算法計算數據的校驗和，通過對文件的內容或目錄的結構計算出一個?SHA-1?哈希值，作為指紋字符串。該字串由?40?個十六進制字符（0-9?及?a-f）組成，看起來就像是： ~~~ 24b9da6552252987aa493b52f8696cd6d3b00373 ~~~ Git?的工作完全依賴于這類指紋字串，所以你會經常看到這樣的哈希值。實際上，所有保存在?Git?數據庫中的東西都是用此哈希值來作索引的，而不是靠文件名。 ### 多數操作僅添加數據 常用的?Git?操作大多僅僅是把數據添加到數據庫。因為任何一種不可逆的操作，比如刪除數據，都會使回退或重現歷史版本變得困難重重。在別的?VCS?中，若還未提交更新，就有可能丟失或者混淆一些修改的內容，但在?Git?里，一旦提交快照之后就完全不用擔心丟失數據，特別是養成定期推送到其他倉庫的習慣的話。 這種高可靠性令我們的開發工作安心不少，盡管去做各種試驗性的嘗試好了，再怎樣也不會弄丟數據。至于?Git?內部究竟是如何保存和恢復數據的，我們會在第九章討論?Git?內部原理時再作詳述。 ### 文件的三種狀態 好，現在請注意，接下來要講的概念非常重要。對于任何一個文件，在?Git?內都只有三種狀態：已提交（committed），已修改（modified）和已暫存（staged）。已提交表示該文件已經被安全地保存在本地數據庫?中了；已修改表示修改了某個文件，但還沒有提交保存；已暫存表示把已修改的文件放在下次提交時要保存的清單中。 由此我們看到?Git?管理項目時，文件流轉的三個工作區域：Git?的工作目錄，暫存區域，以及本地倉庫。  圖?1-6.?工作目錄，暫存區域，以及本地倉庫 每個項目都有一個?Git?目錄（譯注：如果?git?clone?出來的話，就是其中?.git?的目錄；如果git?clone?--bare?的話，新建的目錄本身就是?Git?目錄。），它是?Git?用來保存元數據和對象數據庫的地方。該目錄非常重要，每次克隆鏡像倉庫的時候，實際拷貝的就是這個目錄里面的數據。 從項目中取出某個版本的所有文件和目錄，用以開始后續工作的叫做工作目錄。這些文件實際上都是從?Git?目錄中的壓縮對象數據庫中提取出來的，接下來就可以在工作目錄中對這些文件進行編輯。 所謂的暫存區域只不過是個簡單的文件，一般都放在?Git?目錄中。有時候人們會把這個文件叫做索引文件，不過標準說法還是叫暫存區域。 基本的?Git?工作流程如下： 1.?在工作目錄中修改某些文件。 2.?對修改后的文件進行快照，然后保存到暫存區域。 3.?提交更新，將保存在暫存區域的文件快照永久轉儲到?Git?目錄中。 所以，我們可以從文件所處的位置來判斷狀態：如果是?Git?目錄中保存著的特定版本文件，就屬于已提交狀態；如果作了修改并已放入暫存區域，就屬于已暫存狀態；如果自上次取出后，作了修改但還沒有放到暫存區域，就?是已修改狀態。到第二章的時候，我們會進一步了解其中細節，并學會如何根據文件狀態實施后續操作，以及怎樣跳過暫存直接提交。 ## 1.4?安裝?Git 是時候動手嘗試下?Git?了，不過得先安裝好它。有許多種安裝方式，主要分為兩種，一種是通過編譯源代碼來安裝；另一種是使用為特定平臺預編譯好的安裝包。 ### 從源代碼安裝 若是條件允許，從源代碼安裝有很多好處，至少可以安裝最新的版本。Git?的每個版本都在不斷嘗試改進用戶體驗，所以能通過源代碼自己編譯安裝最新版本就再好不過了。有些?Linux?版本自帶的安裝包更新起來并不及時，所以除非你在用最新的?distro?或者?backports，那么從源代碼安裝其實該算是最佳選擇。 Git?的工作需要調用?curl，zlib，openssl，expat，libiconv?等庫的代碼，所以需要先安裝這些依賴工具。在有?yum?的系統上（比如?Fedora）或者有?apt-get?的系統上（比如?Debian?體系），可以用下面的命令安裝： ~~~ $ yum installcurl-devel expat-devel gettext-devel \ openssl-devel zlib-devel $ apt-get installlibcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev ~~~ 之后，從下面的?Git?官方站點下載最新版本源代碼：`http:``//git-scm``.com``/download` 然后編譯并安裝： ~~~ $tar-zxf git-1.7.2.2.tar.gz $cdgit-1.7.2.2 $makeprefix=/usr/localall $sudomakeprefix=/usr/localinstall ~~~ 現在已經可以用?git?命令了，用?git?把?Git?項目倉庫克隆到本地，以便日后隨時更新： ~~~ $ git clone git://git.kernel.org/pub/scm/git/git.git ~~~ ### 在?Linux?上安裝 如果要在?Linux?上安裝預編譯好的?Git?二進制安裝包，可以直接用系統提供的包管理工具。在?Fedora?上用?yum?安裝： ~~~ $ yum installgit-core ~~~ 在?Ubuntu?這類?Debian?體系的系統上，可以用?apt-get?安裝： ~~~ $ apt-get installgit-core ~~~ ### 在?Mac?上安裝 在?Mac?上安裝?Git?有兩種方式。最容易的當屬使用圖形化的?Git?安裝工具，界面如圖?1-7，下載地址在：http://code.gogle.com/p/git-osx-installer o 圖 1-7. Git OS X 安裝工具 另一種是通過?MacPorts?(http://www.macports.org)?安裝。如果已經裝好了?MacPorts，用下面的命令安裝?Git： ~~~ $sudoportinstallgit-core +svn +doc +bash_completion +gitweb ~~~ 這種方式就不需要再自己安裝依賴庫了，Macports?會幫你搞定這些麻煩事。一般上面列出的安裝選項已經夠用，要是你想用?Git?連接?Subversion?的代碼倉庫，還可以加上?+svn?選項，具體將在第八章作介紹。（譯注：還有一種是使用?homebrew（https://github.com/mxcl/homebrew）：brew?install?git。） ### 在?Windows?上安裝 在?Windows?上安裝?Git?同樣輕松，有個叫做?msysGit?的項目提供了安裝包，可以到?Google?Code?的頁面上下載?exe?安裝文件并運行： ~~~ http://code.google.com/p/msysgit ~~~ 完成安裝之后，就可以使用命令行的?git?工具（已經自帶了?ssh?客戶端）了，另外還有一個圖形界面的?Git?項目管理工具。 ## 1.5?初次運行?Git?前的配置 一般在新的系統上，我們都需要先配置下自己的?Git?工作環境。配置工作只需一次，以后升級時還會沿用現在的配置。當然，如果需要，你隨時可以用相同的命令修改已有的配置。 Git?提供了一個叫做?git?config?的工具（譯注：實際是?git-config?命令，只不過可以通過?git?加一個名字來呼叫此命令。），專門用來配置或讀取相應的工作環境變量。而正是由這些環境變量，決定了?Git?在各個環節的具體工作方式和行為。這些變量可以存放在以下三個不同的地方： l?/etc/gitconfig?文件：系統中對所有用戶都普遍適用的配置。若使用?git?config?時用--system?選項，讀寫的就是這個文件。 l?~/.gitconfig?文件：用戶目錄下的配置文件只適用于該用戶。若使用?git?config?時用--global?選項，讀寫的就是這個文件。 l?當前項目的?git?目錄中的配置文件（也就是工作目錄中的?.git/config?文件）：這里的配置僅僅針對當前項目有效。每一個級別的配置都會覆蓋上層的相同配置，所以.git/config?里的配置會覆蓋/etc/gitconfig?中的同名變量。 在?Windows?系統上，Git?會找尋用戶主目錄下的?.gitconfig?文件。主目錄即?$HOME?變量指定的目錄，一般都是C:\Documents?and?Settings\$USER。此外，Git?還會嘗試找尋/etc/gitconfig?文件，只不過看當初?Git?裝在什么目錄，就以此作為根目錄來定位。 ### 用戶信息 第一個要配置的是你個人的用戶名稱和電子郵件地址。這兩條配置很重要，每次?Git?提交時都會引用這兩條信息，說明是誰提交了更新，所以會隨更新內容一起被永久納入歷史記錄： ~~~ $ git config --global user.name "John Doe" $ git config --global user.email johndoe@ example.com ~~~ 如果用了?--global?選項，那么更改的配置文件就是位于你用戶主目錄下的那個，以后你所有的項目都會默認使用這里配置的用戶信息。如果要在某個特定的項目中使用其他名字或者電郵，只要去掉--global?選項重新配置即可，新的設定保存在當前項目的.git/config?文件里。 ### 文本編輯器 接下來要設置的是默認使用的文本編輯器。Git?需要你輸入一些額外消息的時候，會自動調用一個外部文本編輯器給你用。默認會使用操作系統指定的默認編輯器，一般可能會是?Vi?或者?Vim。如果你有其他偏好，比如?Emacs?的話，可以重新設置： ~~~ $ git config --global core.editor emacs ~~~ ### 差異分析工具 還有一個比較常用的是，在解決合并沖突時使用哪種差異分析工具。比如要改用?vimdiff?的話： ~~~ $ git config --global merge.tool vimdiff ~~~ Git?可以理解?kdiff3，tkdiff，meld，xxdiff，emerge，vimdiff，gvimdiff，ecmerge，和?opendiff?等合并工具的輸出信息。當然，你也可以指定使用自己開發的工具，具體怎么做可以參閱第七章。 ### 查看配置信息 要檢查已有的配置信息，可以使用?git?config?--list?命令： ~~~ $ git config --list user.name=Scott Chacon user.email=schacon@ gmail.com color.status=auto color.branch=auto color.interactive=auto color.diff=auto ... ~~~ 有時候會看到重復的變量名，那就說明它們來自不同的配置文件（比如?/etc/gitconfig?和?~/.gitconfig），不過最終?Git?實際采用的是最后一個。 也可以直接查閱某個環境變量的設定，只要把特定的名字跟在后面即可，像這樣： ~~~ $ git config user.name Scott Chacon ~~~ ## 1.6?獲取幫助 想了解?Git?的各式工具該怎么用，可以閱讀它們的使用幫助，方法有三： ~~~ $ git help $ git --help $mangit- ~~~ 比如，要學習?config?命令可以怎么用，運行： ~~~ $ git help config ~~~ 我們隨時都可以瀏覽這些幫助信息而無需連網。不過，要是你覺得還不夠，可以到?Frenode?IRC?服務器（irc.freenode.net）上的?#git?或?#github?頻道尋求他人幫助。這兩個頻道上總有著上百號人，大多都有著豐富的?git?知識，并且樂于助人。 ## 1.7?小結 至此，你該對?Git?有了點基本認識，包括它和以前你使用的?CVCS?之間的差別。現在，在你的系統上應該已經裝好了?Git，設置了自己的名字和電郵。接下來讓我們繼續學習?Git?的基礎知識。