Git 基礎(chǔ)

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

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

Git 和其他版本控制系統(tǒng)的主要差別在于，Git 只關(guān)心文件數(shù)據(jù)的整體是否發(fā)生變化，而大多數(shù)其他系統(tǒng)則只關(guān)心文件內(nèi)容的具體差異。這類系統(tǒng)（CVS，Subversion，Perforce，Bazaar 等等）每次記錄有哪些文件作了更新，以及都更新了哪些行的什么內(nèi)容，請(qǐng)看圖 1-4。

圖 1-5. Git 保存每次更新時(shí)的文件快照

這是 Git 同其他系統(tǒng)的重要區(qū)別。它完全顛覆了傳統(tǒng)版本控制的套路，并對(duì)各個(gè)環(huán)節(jié)的實(shí)現(xiàn)方式作了新的設(shè)計(jì)。Git 更像是個(gè)小型的文件系統(tǒng)，但它同時(shí)還提供了許多以此為基礎(chǔ)的超強(qiáng)工具，而不只是一個(gè)簡(jiǎn)單的 VCS。稍后在第三章討論 Git 分支管理的時(shí)候，我們會(huì)再看看這樣的設(shè)計(jì)究竟會(huì)帶來哪些好處。

近乎所有操作都是本地執(zhí)行

在 Git 中的絕大多數(shù)操作都只需要訪問本地文件和資源，不用連網(wǎng)。但如果用 CVCS 的話，差不多所有操作都需要連接網(wǎng)絡(luò)。因?yàn)?Git 在本地磁盤上就保存著所有當(dāng)前項(xiàng)目的歷史更新，所以處理起來速度飛快。

舉個(gè)例子，如果要瀏覽項(xiàng)目的歷史更新摘要，Git 不用跑到外面的服務(wù)器上去取數(shù)據(jù)回來，而直接從本地?cái)?shù)據(jù)庫讀取后展示給你看。所以任何時(shí)候你都可以馬上翻閱，無需等待。如果想要看當(dāng)前版本的文件和一個(gè)月前的版本之間有何差異，Git 會(huì)取出一個(gè)月前的快照和當(dāng)前文件作一次差異運(yùn)算，而不用請(qǐng)求遠(yuǎn)程服務(wù)器來做這件事，或是把老版本的文件拉到本地來作比較。

用 CVCS 的話，沒有網(wǎng)絡(luò)或者斷開 VPN 你就無法做任何事情。但用 Git 的話，就算你在飛機(jī)或者火車上，都可以非常愉快地頻繁提交更新，等到了有網(wǎng)絡(luò)的時(shí)候再上傳到遠(yuǎn)程倉庫。同樣，在回家的路上，不用連接 VPN 你也可以繼續(xù)工作。換作其他版本控制系統(tǒng)，這么做幾乎不可能，抑或非常麻煩。比如 Perforce，如果不連到服務(wù)器，幾乎什么都做不了（譯注：默認(rèn)無法發(fā)出命令 p4 edit file 開始編輯文件，因?yàn)?Perforce 需要聯(lián)網(wǎng)通知系統(tǒng)聲明該文件正在被誰修訂。但實(shí)際上手工修改文件權(quán)限可以繞過這個(gè)限制，只是完成后還是無法提交更新。）；如果是 Subversion 或 CVS，雖然可以編輯文件，但無法提交更新，因?yàn)閿?shù)據(jù)庫在網(wǎng)絡(luò)上?？瓷先ズ孟襁@些都不是什么大問題，但實(shí)際體驗(yàn)過之后，你就會(huì)驚喜地發(fā)現(xiàn)，這其實(shí)是會(huì)帶來很大不同的。

時(shí)刻保持?jǐn)?shù)據(jù)完整性

在保存到 Git 之前，所有數(shù)據(jù)都要進(jìn)行內(nèi)容的校驗(yàn)和（checksum）計(jì)算，并將此結(jié)果作為數(shù)據(jù)的唯一標(biāo)識(shí)和索引。換句話說，不可能在你修改了文件或目錄之后，Git 一無所知。這項(xiàng)特性作為 Git 的設(shè)計(jì)哲學(xué)，建在整體架構(gòu)的最底層。所以如果文件在傳輸時(shí)變得不完整，或者磁盤損壞導(dǎo)致文件數(shù)據(jù)缺失，Git 都能立即察覺。

Git 使用 SHA-1 算法計(jì)算數(shù)據(jù)的校驗(yàn)和，通過對(duì)文件的內(nèi)容或目錄的結(jié)構(gòu)計(jì)算出一個(gè) SHA-1 哈希值，作為指紋字符串。該字串由 40 個(gè)十六進(jìn)制字符（0-9 及 a-f）組成，看起來就像是：

24b9da6552252987aa493b52f8696cd6d3b00373

Git 的工作完全依賴于這類指紋字串，所以你會(huì)經(jīng)?？吹竭@樣的哈希值。實(shí)際上，所有保存在 Git 數(shù)據(jù)庫中的東西都是用此哈希值來作索引的，而不是靠文件名。

多數(shù)操作僅添加數(shù)據(jù)

常用的 Git 操作大多僅僅是把數(shù)據(jù)添加到數(shù)據(jù)庫。因?yàn)槿魏我环N不可逆的操作，比如刪除數(shù)據(jù)，都會(huì)使回退或重現(xiàn)歷史版本變得困難重重。在別的 VCS 中，若還未提交更新，就有可能丟失或者混淆一些修改的內(nèi)容，但在 Git 里，一旦提交快照之后就完全不用擔(dān)心丟失數(shù)據(jù)，特別是養(yǎng)成定期推送到其他倉庫的習(xí)慣的話。

這種高可靠性令我們的開發(fā)工作安心不少，盡管去做各種試驗(yàn)性的嘗試好了，再怎樣也不會(huì)弄丟數(shù)據(jù)。至于 Git 內(nèi)部究竟是如何保存和恢復(fù)數(shù)據(jù)的，我們會(huì)在第九章討論 Git 內(nèi)部原理時(shí)再作詳述。

文件的三種狀態(tài)

好，現(xiàn)在請(qǐng)注意，接下來要講的概念非常重要。對(duì)于任何一個(gè)文件，在 Git 內(nèi)都只有三種狀態(tài)：已提交（committed），已修改（modified）和已暫存（staged）。已提交表示該文件已經(jīng)被安全地保存在本地?cái)?shù)據(jù)庫中了；已修改表示修改了某個(gè)文件，但還沒有提交保存；已暫存表示把已修改的文件放在下次提交時(shí)要保存的清單中。

由此我們看到 Git 管理項(xiàng)目時(shí)，文件流轉(zhuǎn)的三個(gè)工作區(qū)域：Git 的工作目錄，暫存區(qū)域，以及本地倉庫。

圖 1-6. 工作目錄，暫存區(qū)域，以及本地倉庫

每個(gè)項(xiàng)目都有一個(gè) Git 目錄（譯注：如果 git clone 出來的話，就是其中 .git 的目錄；如果 git clone --bare 的話，新建的目錄本身就是 Git 目錄。），它是 Git 用來保存元數(shù)據(jù)和對(duì)象數(shù)據(jù)庫的地方。該目錄非常重要，每次克隆鏡像倉庫的時(shí)候，實(shí)際拷貝的就是這個(gè)目錄里面的數(shù)據(jù)。

從項(xiàng)目中取出某個(gè)版本的所有文件和目錄，用以開始后續(xù)工作的叫做工作目錄。這些文件實(shí)際上都是從 Git 目錄中的壓縮對(duì)象數(shù)據(jù)庫中提取出來的，接下來就可以在工作目錄中對(duì)這些文件進(jìn)行編輯。

所謂的暫存區(qū)域只不過是個(gè)簡(jiǎn)單的文件，一般都放在 Git 目錄中。有時(shí)候人們會(huì)把這個(gè)文件叫做索引文件，不過標(biāo)準(zhǔn)說法還是叫暫存區(qū)域。

基本的 Git 工作流程如下：

1. 在工作目錄中修改某些文件。
2. 對(duì)修改后的文件進(jìn)行快照，然后保存到暫存區(qū)域。
3. 提交更新，將保存在暫存區(qū)域的文件快照永久轉(zhuǎn)儲(chǔ)到 Git 目錄中。

所以，我們可以從文件所處的位置來判斷狀態(tài)：如果是 Git 目錄中保存著的特定版本文件，就屬于已提交狀態(tài)；如果作了修改并已放入暫存區(qū)域，就屬于已暫存狀態(tài)；如果自上次取出后，作了修改但還沒有放到暫存區(qū)域，就是已修改狀態(tài)。

到第二章的時(shí)候，我們會(huì)進(jìn)一步了解其中細(xì)節(jié)，并學(xué)會(huì)如何根據(jù)文件狀態(tài)實(shí)施后續(xù)操作，以及怎樣跳過暫存直接提交。