深入理解Git的實現原理
原文地址：https://www.cnblogs.com/mamingqian/p/9711975.html
0、導讀
本文適合對git有過接觸，但知其然不知其所以然的小夥伴，也適合想要學習git的初學者，通過這篇文章，能讓大家對git有豁然開朗的感覺。在寫作過程中，我力求通俗易懂，深入淺出，不堆砌概念。你能夠從本文中瞭解以下知識：
- Git是什麼
- Git能夠解決哪些問題
- Git的實現原理
請注意,本文的闡述邏輯是：Git是什麼——>Git要解決的根本問題是什麼——>git是如何解決這些問題的。
1、Git是什麼？
Git是一種分散式版本控制系統。
有人要問了，什麼是“版本控制”？Git又為什麼被冠以“分散式”的名頭呢？這兩個問題我們一一解答。
版本控制這個說法多少有一點抽象。事實上，版本控制這件事兒我們一直在做，只是平時不這麼稱呼。舉一個栗子，boss讓你寫一個策劃案，你先完成了一稿，之後又有了一些新的想法，但是並不確定新的想法是否能得到boss的認可，於是你儲存了一個初稿，之後在初稿的基礎上另存了一個檔案，做了部分修改完成了一個修改稿。OK，這時你的策劃案就有了兩個版本——初稿和修改稿。如果boss對修改稿不滿意，你可以很輕易的把初稿拿出來交差。
在這個簡單的過程中，你已經執行了一個簡單的版本控制操作——把文件儲存為初稿和修改稿的過程就是版本控制。
學術點說，版本控制就是對檔案變更過程的管理。說白了，版本控制就是要把一個檔案或一些檔案的各個版本按一定的方式管理起來，目的是需要用到某個版本的時候可以隨時拿出來。
另一個個問題，為什麼說Git是“分散式”版本控制系統呢？
這裡的“分散式”是相對於“集中式”來說的。把資料集中儲存在伺服器節點，所有的客戶節點都從服務節點獲取資料的版本控制系統叫做集中式版本控制系統，比如svn就是典型的集中式版本控制系統。
與之相對，Git的資料不止儲存在伺服器上，同時也完整的儲存在本地計算機上，所以我們稱Git為分散式版本控制系統。
Git的這種特性帶來許多便利，比如你可以在完全離線的情況下使用Git，隨時隨地提交專案更新，而且你不必為單點故障過分擔心，即使伺服器宕機或資料損毀，也可以用任何一個節點上的資料恢復專案，因為每一個開發節點都儲存著完整的專案檔案映象。
2、Git能夠解決哪些問題？
就像上文舉的例子一樣，在未接觸版本控制系統之前，大多人會通過儲存專案或檔案的備份來達到版本控制的目的。通常你的檔案或資料夾名會設定成“XXX-v1.0”、“XXX-v2.0”等。
這是一種簡單的辦法，但過於簡單。這種方式無法詳細記錄版本附加資訊，難以應付複雜專案或長期更新的專案，缺乏版本控制約定，對協作開發無能為力。如果你不慎使用了這種方式，那麼稍稍過一段時間你就會發現連自己都不知道每個版本間的區別，版本控制形同虛設。
Git能夠為我們解決版本控制方面的大多數問題，利用Git
- 我們可以為每一次變更提交版本更新並且備註更新的內容；
- 我們可以在專案的各個歷史版本之間自如切換；
- 我們可以一目瞭然的比較出兩個版本之間的差異；
- 我們可以從當前的修改中撤銷一些操作；
- 我們可以自如的建立分支、合併分支；
- 我們可以和多人協作開發；
- 我們可以採取自由多樣的開發模式。
諸如此類，數不勝數。然而實現這些功能的基礎是對檔案變更過程的儲存。如果我們能抓住這個根本，提綱挈領的學習git，會事半功倍。
隨著對Git更深入的學習，你會發現它會變得越來越簡單，越來越純粹。道家有萬法歸宗的說法，用在這裡再合適不過。因為Git之所以有如此多炫酷的功能，根源只有一個：它很好的解決了檔案變更過程儲存這一個問題。
所以，如果問“Git能夠解決哪些問題？”我們可以簡單的回答：Git解決了版本控制方面的很多問題，但最核心的是它很好的解決了版本狀態儲存（即檔案變更過程儲存）的問題。
3、Git的實現原理
我們說到，Git很好的解決了版本狀態記錄的問題，在此基礎上實現了版本切換、差異比較、分支管理、分散式協作等等炫酷功能。那麼，這一節我們就先從最根本的講起，看看Git是如何解決版本狀態記錄（即檔案變更過程記錄）問題的。
我們都有版本記錄的經驗，比如在文件撰寫的關鍵點上保留一個備份，或在需要對檔案進行修改的時候“另存”一次。這都是很好的習慣，也是版本狀態記錄的一種常用方式。事實上，Git採取了差不多的方式。
在我們向Git系統提交一個版本的時候，Git會把這個版本完整儲存下來。這是不是和“另存”有異曲同工之妙呢？不同之處在於儲存方式，在Git系統中一旦一個版本被提交，那麼它就會被儲存在“Git資料庫”中。
3.1 Git資料庫
我們提到了“Git資料庫”，這是什麼玩意兒呢？為了能夠說清楚Git資料庫的概念，我們暫且引入三個Git指令，通過這三個命令，我們就能一探git資料庫的究竟。
- git init 用於建立一個空的git倉庫，或重置一個已存在的git倉庫
- git hash-object git底層命令，用於向Git資料庫中寫入資料
- git cat-file git底層命令，用於檢視Git資料庫中資料
首先，我們用git init新建一個空的git倉庫。（希望小夥伴們可以跟著我的節奏一起來實際操作一下，會加深理解。如果有還沒有安裝好git工具的同學，請自行百度安裝，我不會講安裝的過程。）
我用的是ubuntu系統，在terminal下執行
| $ git init GitTest Initialized empty Git repository in /home/mp/Workspace/GitTest/.git/ |
這一命令在當前目錄下生成了一個新的資料夾-GitTest，在GitTest中，包含了一個新建的空git倉庫。如果你不明白git倉庫是什麼，那麼可以簡單的理解為存放git資料的一個空間，這這個例子中，是“/home/mp/Workspace/GitTest/.git”目錄。
接下來，我們看看git倉庫的結構是什麼樣的。執行
| $ cd GitTest $ ls $ find .git .git |
我們發現，GitTest目錄下，除隱藏目錄.git之外，並沒有其他檔案或資料夾。
我們通過find .git命令檢視新生成的空git倉庫的結構，會發現其中有一個objects資料夾，這就是git資料庫的儲存位置。
3.1 Git資料庫的寫入操作
緊接著，我們利用git底層命令git hash-object向git資料庫中寫入一些內容。執行命令：
| $ echo "version 1" | git hash-object -w --stdin 83baae61804e65cc73a7201a7252750c76066a30 $ find .git/objects/ -type f |
"|"表示這是一條通道命令，意思是把“|”前邊的命令的輸出作為“|”後邊命令的輸入。git hash-object -w --stdin 的意思是向git資料庫中寫入一條資料（-w）,這條資料的內容從標準輸入中讀取（--stdin）。
命令執行後，會返回個長度為40位的hash值，這個hash值是將待儲存的資料外加一個頭部資訊一起做SHA-1校驗運算而得的校驗和。在git資料庫中，它有一個名字，叫做“鍵值（key）”。相應的，git資料庫其實是一個簡單的“鍵值對（key-value）”資料庫。事實上，你向該資料庫中插入任意型別的內容，它都會返回一個鍵值。通過返回的鍵值可以在任意時刻再次檢索該內容。
此時，我們再次執行find .git/objects/ -type f命令檢視objects目錄，會發現目錄中多出了一個檔案，這個檔案儲存在以新存入資料對應hash值的前2位命名的資料夾內，檔名為hash值的後38位。這就是git資料庫的儲存方式，一個檔案對應一條內容，就是這麼簡單直接。
3.2 Git資料庫的查詢操作
我們可以通過git cat-file這個git底層命令檢視資料庫中某一鍵值對應的資料。執行
| $ git cat-file -t 83baa blob $ git cat-file -p 83baa version 1 |
其中，-t選項用於檢視鍵值對應資料的型別，-p選項用於檢視鍵值對應的資料內容，83bba為資料鍵值的簡寫。
由執行結果可見，所查詢的鍵值對應的資料型別為blob，資料內容為“version 1”。blob物件我們稱之為資料物件，這是git資料庫能夠儲存的物件型別之一，後面我們還會講到另外兩種物件分別是樹（tree）物件和提交（commit）物件。
截止到這裡，你已經掌握瞭如何向git資料庫裡存入內容和取出內容。這很簡單但是卻意義非凡，因為對git資料庫的操作正是git系統的核心——git的版本控制功能就是基於它的物件資料庫實現的。在git資料庫裡，儲存著納入git版本管理的所有檔案的所有版本的完整映象。
git這麼簡單嗎？不用懷疑，git就是這麼簡單，我們已經準確的抓住了它的根本要義——物件資料庫。接下來我們會利用git資料庫搭建起git的高樓大廈。
3.3 使用Git跟蹤檔案變更
我們明白，所謂跟蹤檔案變更，只不過是把檔案變更過程中的各個狀態完整記錄下來。
我們模擬一次檔案變更的過程，看看僅僅利用git的物件資料庫能不能實現“跟蹤檔案變更”的功能。
首先，我們執行
| $ echo "version 1" > file.txt
$ git hash-object -w file.txt 83baae61804e65cc73a7201a7252750c76066a30 |
我們把文字“version 1”寫入file.txt中，並利用git hash-object -w file.txt命令將其儲存入資料庫中。如果你足夠細心，會發現返回的hash鍵值和利用echo "version 1" | git hash-object -w --stdin寫入資料庫時是一致的，這很正常，因為我們寫入的內容相同。git hash-object命令在只指定-w選項的時候，會把file.txt檔案內容寫入資料庫。
此時，執行
| $ find .git/objects -type f .git/objects/83/baae61804e65cc73a7201a7252750c76066a30 |
會發現.git/objects目錄中，依然只有一個檔案。可見，git資料庫儲存檔案時，只關心檔案內容，與檔案的名字無關。
接下來，我們修改file.txt的內容，執行
| $ echo "version 2" > file.txt $ git hash-object -w file.txt 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a $ find .git/objects -type f .git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a |
我們發現，.git/objects下多出了一個檔案，這是我們新儲存進資料庫的file.txt。接下來，我們執行git cat-file搞清楚這兩條資料的內容分別是什麼。執行
| $git cat-file -p 83baa version 1 $git cat-file -p 1f7a7a version 2 |
我們發現，file.txt的變更過程被完整的記錄下來了。
當前的file.txt中儲存的內容是“version 2”，如果我們想把檔案恢復到修改為“version 2”之前的狀態，只需執行
| $ cat file.txt $ git cat-file -p 83baa > file.txt $ cat file.txt |
file.txt的內容成功恢復到了修改前的狀態，變成了“version 1”。這其實就是版本回滾的實質。
OK，檔案變更狀態跟蹤的道理就是這麼簡單。
但做到這一步還遠遠不算完美，至少有以下幾方面的問題：
- 第一，無法記錄檔名的變化；
- 第二，無法記錄資料夾的變化；
- 第三，記憶每一個版本對應的hash值無聊且乏味且不可能；
- 第四，無法得知檔案的變更時序；
- 第五，缺少對每一次版本變化的說明。
問題不少，但都是簡單的小問題，我們一一解決。
3.4 利用樹物件（tree object）解決檔名儲存和檔案組織問題
Git利用樹物件（tree object）解決檔名儲存的問題，樹物件也能夠將多個檔案組織在一起。
Git通過樹（tree）物件將資料（blob）物件組織起來，這很類似於一種檔案系統——blob物件對應檔案內容，tree物件對應檔案的目錄和節點。一個樹（tree）物件包含一條或多條記錄，每條記錄含有一個指向blob物件或tree物件的SHA-1指標，以及相應的模式、型別、檔名。
有了樹物件，我們就可以將檔案系統任何時間點的狀態儲存在git資料庫中，這是不是很激動人心呢？你的一個複雜的專案可能包含成百上千個檔案和檔案目錄，有了樹物件，這一切都不是問題。
建立樹物件
通常，Git根據某一時刻暫存區所表示的狀態建立並記錄一個對應的樹物件，如此重複便可以依次記錄一系列的樹物件。Git的暫存區是一個檔案——.git/index。下面，我們通過建立樹物件的過程來認識暫存區和樹物件。
為了建立一個樹物件，我們需要通過暫存一些檔案來建立一個暫存區。為此我們引入兩個命令：
- git update-index git底層命令，用於建立暫存區
- git ls-files --stage git底層命令，用於檢視暫存區內容
- git write-tree git底層命令，用於將暫存區內容寫入一個樹物件
OK，萬事俱備，我們將file.txt的第一個版本放入暫存區，執行
| $ find .git/index find: ‘.git/index’: No such file or directory $ git update-index --add file.txt $ find .git/index .git/index $ cat .git/index DIRC[���$�;�[���$�;�A���� ���a�Ne�s� rRu vjfile.txt�݀3%A��,I� �` $ find .git/objects/ -type f .git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a .git/objects/83/baae61804e65cc73a7201a7252750c76066a30 $ git ls-files --stage 100644 83baae61804e65cc73a7201a7252750c76066a30 0 file.txt $ git write-tree 391a4e90ba882dbc9ea93855103f6b1fa6791cf6 $ find .git/objects/ -type f .git/objects/39/1a4e90ba882dbc9ea93855103f6b1fa6791cf6 .git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a .git/objects/83/baae61804e65cc73a7201a7252750c76066a30 |
分析執行結果：
首先，我們注意.git/index檔案的變化。在新增file.txt到暫存區前，index檔案並不存在，這說明暫存區還沒有建立。新增file.txt到暫存區的同時，index檔案被建立。
其次，我們看git資料庫的變化。我們發現在執行git update-index 之後，git資料庫並沒有改變，依然是隻有兩條資料。在執行git write-tree之後，git資料庫中多出了一條新的記錄，鍵值為391a4e90ba882dbc9ea93855103f6b1fa6791cf6。
我們執行git cat-file來檢視一下多出來的這條記錄是什麼內容。執行
| $ git cat-file -t 391a4e tree $ git cat-file -p 391a4e 100644 blob 83baae61804e65cc73a7201a7252750c76066a30 file.txt |
由執行結果可見，git資料庫中新增加的記錄是一個tree物件，該tree物件指向一個blob物件，hash鍵值為
| 83baae61804e65cc73a7201a7252750c76066a30 |
這一個blob物件是之前我們新增進資料庫的。
以上我們添加了一個已經存在在git資料庫中的檔案到暫存區，如果我們新建一個未曾儲存到git資料庫的檔案存入暫存區，進而儲存為tree物件，會有什麼不同嗎？我們試試看。執行
| $ echo "new file" > new $ git ls-files --stage |
由執行結果我們可以看到，這一次執行update-index之後，和上次不同，git資料庫發生了變化，新增加了一條hash鍵值為“fa49b0”的資料；暫存區中也多出了檔案new的資訊。
這說明兩個問題：
- 如果新增git資料庫中尚未儲存的資料到暫存區，則在執行update-index的時候，會同時把該資料儲存到git資料庫。
- 新增檔案進入暫存區的操作是追加操作，之前已經加入暫存區的檔案依然存在——很多人會有誤區，認為變更提交之後，暫存區就清空了。
此時，我們檢視新新增的樹物件，執行
| $ git cat-file -p 228e49 100644 blob 83baae61804e65cc73a7201a7252750c76066a30 file.txt 100644 blob fa49b077972391ad58037050f2a75f74e3671e92 new |
此次write-tree寫入資料庫的是tree物件包含了兩個檔案。
更進一步，我們是否能將一個子資料夾儲存到樹物件呢？嘗試一下，執行
| $ mkdir new_dir $ git update-index --add new_dir error: new_dir: is a directory - add files inside instead fatal: Unable to process path new_dir |
我們發現，無法將一個新建的空資料夾新增到暫存區。錯誤提示告訴我們，應該將檔案將資料夾中的檔案加入到暫存區（add files inside instead）。
OK，接下來，我們在新建的資料夾下寫入一個檔案，再嘗試將這一檔案加入暫存區。執行
| $ echo "file in new dir" > new_dir/new $ git write-tree $ git cat-file -p 06564b |
從執行結果可見，資料夾new_dir對應一個tree物件。
至此，在git資料庫中，我們可以完整的記錄檔案的狀態、資料夾的狀態；並且可以把多個檔案或資料夾組織在一起，記錄他們的變更過程。我們離一個完善的版本控制系統似乎已經不遠了，而這一切實現起來又是如此簡單——我們只是通過幾個命令操作git資料庫就完成了這些功能。
接下來，我們只要把資料庫中各個版本的時序關係記錄下來，再把對每一個版本更新的註釋記錄下來，不就完成了一個邏輯簡單、功能強大、操作靈活的版本控制系統嗎？
那麼，如何記錄版本的時序關係，如何記錄版本的更新註釋呢？這就要引入另一個git資料物件——提交物件（commit object）。
3.5 利用提交物件（commit object）記錄版本間的時序關係和版本註釋
commit物件能夠幫你記錄什麼時間，由什麼人，因為什麼原因提交了一個新的版本，這個新的版本的父版本又是誰。
git提供了底層命令commit-tree來建立提交物件（commit object），我們需要為這個命令指定一個被提交的樹物件的hash鍵值，以及該提交物件的父提交物件（如果是第一次提交，不需要指定父物件）。
我們嘗試將之前建立的樹物件提交為commit 物件，執行
| $ git write-tree cb0fbcc484a3376b3e70958a05be0299e57ab495 $ git commit-tree cb0fbcc -m "first commit" 7020a97c0e792f340e00e1bb8edcbafcc4dfb60f $ git cat-file 7020a97 tree cb0fbcc484a3376b3e70958a05be0299e57ab495 |
在git commit-tree命令中，-m選項用於指定本次提交的註釋。
我們可以很清楚的看到，一個提交物件包含著所提交版本的樹物件hash鍵值，author和commiter，以及修改和提交的時間，最後是本次提交的註釋。
其中committer和author是通過git config命令設定的。
接下來，修改某個檔案，重新建立一個樹物件，並將這一樹物件提交，作為專案的第二個提交版本。執行
| $ echo "new version" > file.txt $ git update-index file.txt $ git write-tree |
我們可以按照上述步驟，再提交第三個版本。
| $ echo "another version" > file.txt $ git update-index file.txt $ git write-tree 92867fcc5e0f78c195c43d1de25aa78974fa8103 $ git commit-tree 92867 -p e838c -m "third commit" 491404fa6e6f95eb14683c3c06d10ddc5f8e883f $ git cat-file -p 49140 tree 92867fcc5e0f78c195c43d1de25aa78974fa8103 parent e838c8678ef789df84c2666495663060c90975d7 author john <[email protected]> 1537963274 +0800 committer john <[email protected]> 1537963274 +0800
third commit |
提交完三個版本，我們通過git log 檢視最近一個提交物件的提交記錄
| $ git log 49140 commit 491404fa6e6f95eb14683c3c06d10ddc5f8e883f Author: john <[email protected]> Date: Wed Sep 26 20:01:14 2018 +0800 third commit commit e838c8678ef789df84c2666495663060c90975d7 Author: john <[email protected]> Date: Wed Sep 26 19:47:22 2018 +0800 second commit commit 7020a97c0e792f340e00e1bb8edcbafcc4dfb60f Author: john <[email protected]> Date: Wed Sep 26 19:31:18 2018 +0800 first commit |
太神奇了： 就在剛才，我們圍繞git資料庫，僅憑几個底層資料庫操作便完成了一個 Git 提交歷史的建立。到此為止，我們已經完全掌握了git的內在邏輯。
接觸過git的小夥伴會發現，以上我們用到的這些指令在使用git過程中是用不到的。這是為什麼呢？因為git對以上這些指令進行了封裝，給使用者提供了更便捷的操作命令，如add，commit等。
每次我們執行 git add 和 git commit 命令時， Git 所做的實質工作是將被改寫的檔案儲存為資料物件，更新暫存區，記錄樹物件，最後建立一個指明瞭頂層樹物件和父提交的提交物件。 這三種主要的 Git 物件——資料物件、樹物件、提交物件——最初均以單獨檔案的形式儲存在 .git/objects 目錄下。
然而，小問題依然存在，截止目前為止，我們對版本和資料物件的操作都是基於hash鍵值的，這些毫無直觀含義的字串讓人很頭疼，不會有人願意一直急著最新提交對應的hash鍵值的。git不會允許這樣的問題存在的，它通過引入“引用（references）”來解決這一問題。
3.6 Git的引用
Git的引用（references）儲存在.git/refs目錄下。git的引用類似於一個指標，它指向的是某一個hash鍵值。
建立一個引用實在再簡單不過。我們只需把一個git物件的hash鍵值儲存在以引用的名字命名的檔案中即可。
執行
| $ echo "491404fa6e6f95eb14683c3c06d10ddc5f8e883f" > .git/refs/heads/master $ cat .git/refs/heads/master 491404fa6e6f95eb14683c3c06d10ddc5f8e883f |
就這樣，我們便成功的建立了一個指向最新一個提交的引用，引用名為master
在此之前我們檢視提交記錄需要執行 git log 491404，現在只需執行git log master。
| $ git log 491404 commit 491404fa6e6f95eb14683c3c06d10ddc5f8e883f (HEAD -> master) Author: john <[email protected]> Date: Wed Sep 26 20:01:14 2018 +0800 third commit commit e838c8678ef789df84c2666495663060c90975d7 Author: john <[email protected]> Date: Wed Sep 26 19:47:22 2018 +0800 second commit commit 7020a97c0e792f340e00e1bb8edcbafcc4dfb60f Author: john <[email protected]> Date: Wed Sep 26 19:31:18 2018 +0800 first commit $ git log master commit 491404fa6e6f95eb14683c3c06d10ddc5f8e883f (HEAD -> master) Author: john <[email protected]> Date: Wed Sep 26 20:01:14 2018 +0800 third commit commit e838c8678ef789df84c2666495663060c90975d7 Author: john <[email protected]> Date: Wed Sep 26 19:47:22 2018 +0800 second commit commit 7020a97c0e792f340e00e1bb8edcbafcc4dfb60f Author: john <[email protected]> Date: Wed Sep 26 19:31:18 2018 +0800
first commit |
結果完全相同。
Git並不提倡直接編輯引用檔案，它提供了一個底層命令update-ref來建立或修改引用檔案。
echo "491404fa6e6f95eb14683c3c06d10ddc5f8e883f" > .git/refs/heads/master 命令可以簡單的寫作：
| $ git update-ref refs/heads/master 49140 |
這基本就是 Git 分支的本質：一個指向某一系列提交之首的指標或引用。
4. Git基本原理總結
Git的核心是它的物件資料庫，其中儲存著git的物件，其中最重要的是blob、tree和commit物件，blob物件實現了對檔案內容的記錄，tree物件實現了對檔名、檔案目錄結構的記錄，commit物件實現了對版本提交時間、版本作者、版本序列、版本說明等附加資訊的記錄。這三類物件，完美實現了git的基礎功能：對版本狀態的記錄。
Git引用是指向git物件hash鍵值的類似指標的檔案。通過Git引用，我們可以更加方便的定位到某一版本的提交。Git分支、tags等功能都是基於Git引用實現的。