Git的歷史與基礎要點

Git 的歷史

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

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

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

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

Git 基礎要點

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

• 直接快照，而非比較差異

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

圖 1-4. 其他系統在每個版本中記錄著各個文件的具體差異

Git 并不保存這些前后變化的差異數據。實際上，Git 更像是把變化的文件作快照后[快照（Snapshot）的定義是：關于指定數據集合的一個完全可用拷貝，該拷貝包括相應數據在某個時間點（拷貝開始的時間點）的映像。快照可以是其所表示的數據的一個副本，也可以是數據的一個復制品。(來自百度百科)]，記錄在一個微型的文件系統中。每次提交更新時，它會縱覽一遍所有文件的指紋信息并對文件作一快照，然后保存一個指向這次快照的索引。為提高性能，若文件沒有變化，Git 不會再次保存，而只對上次保存的快照作一連接。Git 的工作方式就像圖 1-5 所示。

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

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

• 近乎所有操作都可本地執行

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

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

用 CVCS 的話，沒有網絡或者斷開 V*N 你就無法做任何事情。但用 Git 的話，就算你在飛機或者火車上，都可以非常愉快地頻繁提交更新，等到了有網絡的時候再上傳到遠程的鏡像倉庫。同樣，在回家的路上，不用連接 V*N 你也可以繼續工作。換作其他版本控制系統，這么做幾乎不可能，抑或非常麻煩。比如 Perforce，如果不連到服務器，幾乎什么都做不了（譯注：實際上手工修改文件權限改為可寫之后是可以編輯文件的，只是其他開發者無法通過 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 內都只有三種狀態：已提交（committed），已修改（modified）和已暫存（staged）。已提交表示該文件已經被安全地保存在本地數據庫中了；已修改表示修改了某個文件，但還沒有提交保存；已暫存表示把已修改的文件放在下次提交時要保存的清單中。

由此我們看到 Git 管理項目時，文件流轉的三個工作區域：Git 的本地數據目錄，工作目錄以及暫存區域。

圖 1-6. 工作目錄，暫存區域和 git 目錄

每個項目都有一個 git 目錄，它是 Git 用來保存元數據和對象數據庫的地方。該目錄非常重要，每次克隆鏡像倉庫的時候，實際拷貝的就是這個目錄里面的數據。

從項目中取出某個版本的所有文件和目錄，用以開始后續工作的叫做工作目錄。這些文件實際上都是從 git 目錄中的壓縮對象數據庫中提取出來的，接下來就可以在工作目錄中對這些文件進行編輯。

所謂的暫存區域只不過是個簡單的文件，一般都放在 git 目錄中。有時候人們會把這個文件叫做索引文件，不過標準說法還是叫暫存區域。

基本的 Git 工作流程如下所示：

1. 在工作目錄中修改某些文件。
2. 對這些修改了的文件作快照，并保存到暫存區域。
3. 提交更新，將保存在暫存區域的文件快照轉儲到 git 目錄中。

所 以，我們可以從文件所處的位置來判斷狀態：如果是 git 目錄中保存著的特定版本文件，就屬于已提交狀態；如果作了修改并已放入暫存區域，就屬于已暫存狀態；如果自上次取出后，作了修改但還沒有放到暫存區域，就 是已修改狀態。到第二章的時候，我們會進一步了解個中細節，并學會如何善用這些狀態，以及如何跳過暫存環節。

學習自：http://github.danmarner.com/section/ch1-3/，歡迎一起學習討論，謝謝！
轉自：http://blog.csdn.net/kesenhoo/article/details/7659586