那么,簡單地說,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 的工作目錄,暫存區域,以及本地倉庫。
![2015-05-18/5559aaf0a58b8]
(https://box.kancloud.cn/2015-05-18_5559aaf0a58b8.png)
圖 1-6. 工作目錄,暫存區域,以及本地倉庫
每個項目都有一個 Git 目錄(譯注:如果 `git clone` 出來的話,就是其中 `.git` 的目錄;如果 `git clone --bare` 的話,新建的目錄本身就是 Git 目錄。),它是 Git 用來保存元數據和對象數據庫的地方。該目錄非常重要,每次克隆鏡像倉庫的時候,實際拷貝的就是這個目錄里面的數據。
從項目中取出某個版本的所有文件和目錄,用以開始后續工作的叫做工作目錄。這些文件實際上都是從 Git 目錄中的壓縮對象數據庫中提取出來的,接下來就可以在工作目錄中對這些文件進行編輯。
> 所謂的暫存區域只不過是個簡單的文件,一般都放在 Git 目錄中。有時候人們會把這個文件叫做索引文件,不過標準說法還是叫暫存區域。
基本的 Git 工作流程如下:
1. 在工作目錄中修改某些文件。
2. 對修改后的文件進行快照,然后保存到暫存區域。
3. 提交更新,將保存在暫存區域的文件快照永久轉儲到 Git 目錄中。
所以,我們可以從文件所處的位置來判斷狀態:如果是 Git 目錄中保存著的特定版本文件,就屬于已提交狀態;如果作了修改并已放入暫存區域,就屬于已暫存狀態;如果自上次取出后,作了修改但還沒有放到暫存區域,就是已修改狀態。
到第二章的時候,我們會進一步了解其中細節,并學會如何根據文件狀態實施后續操作,以及怎樣跳過暫存直接提交。
- 1. 起步
- 1.1 關于版本控制
- 1.2 Git 簡史
- 1.3 Git 基礎
- 1.4 安裝 Git
- 1.5 初次運行 Git 前的配置
- 1.6 獲取幫助
- 1.7 小結
- 2. Git基礎
- 2.1 取得項目的 Git 倉庫
- 2.2 記錄每次更新到倉庫
- 2.3 查看提交歷史
- 2.4 撤消操作
- 2.5 遠程倉庫的使用
- 2.6 打標簽
- 2.7 技巧和竅門
- 2.8 小結
- 3. Git分支
- 3.1 何謂分支
- 3.2 分支的新建與合并
- 3.3 分支的管理
- 3.4 利用分支進行開發的工作流程
- 3.5 遠程分支
- 3.6 分支的衍合
- 3.7 小結
- 4. 服務器上的Git
- 4.1 協議
- 4.2 在服務器上部署 Git
- 4.3 生成 SSH 公鑰
- 4.4 架設服務器
- 4.5 公共訪問
- 4.6 GitWeb
- 4.7 Gitosis
- 4.8 Gitolite
- 4.9 Git 守護進程
- 4.10 Git 托管服務
- 4.11 小結
- 5. 分布式Git
- 5.1 分布式工作流程
- 5.2 為項目作貢獻
- 5.3 項目的管理
- 5.4 小結
- 6. Git工具
- 6.1 修訂版本(Revision)選擇
- 6.2 交互式暫存
- 6.3 儲藏(Stashing)
- 6.4 重寫歷史
- 6.5 使用 Git 調試
- 6.6 子模塊
- 6.7 子樹合并
- 6.8 總結
- 7. 自定義Git
- 7.1 配置 Git
- 7.2 Git屬性
- 7.3 Git掛鉤
- 7.4 Git 強制策略實例
- 7.5 總結
- 8. Git與其他系統
- 8.1 Git 與 Subversion
- 8.2 遷移到 Git
- 8.3 總結
- 9. Git 內部原理
- 9.2 Git 對象
- 9.3 Git References
- 9.4 Packfiles
- 9.5 The Refspec
- 9.6 傳輸協議
- 9.7 維護及數據恢復
- 9.8 總結
- 9.1 底層命令 (Plumbing) 和高層命令 (Porcelain)