Git 存儲原理及相關實現

Git 是目前最流行的版本控制系統，從本地開發到生產部署，我們每天都在使用 Git 進行我們的版本控制，除了日常使用的命令之外，如果想要對 Git 有更深一步的了解，那么研究下 Git 的底層存儲原理將會對理解 Git 及其使用非常有幫助，就算你不是一個 Git 開發者，也推薦你了解下 Git 的底層原理，你會對 Git 的強大有一個全新的認識，并且將會在日常的 Git 使用過程中更加得心應手。

這篇文章面向的讀者主要是對 Git 有一定的了解的群體，并不會介紹具體 Git 的作用及其使用，也不會介紹與其它版本控制系統如 Subversion 之間的差異，主要是介紹下 Git 的本質以及他的存儲實現的相關原理，旨在幫助 Git 使用者更加清晰的了解在使用 Git 進行版本控制的時候其內部實現。

Git 本質是什么

Git 本質上是一個內容尋址的 Key-Value 數據庫，我們可以向 Git 倉庫內插入任意類型的內容，Git 會返回給我們一個唯一的鍵值，可以通過這個鍵取出當時我們插入的值，我們可以通過底層命令git hash-object命令來嘗試：

???Zoker?git:(master)???cat?testfile
Hello?Git
???Zoker?git:(master)???git?hash-object?testfile?-w
9f4d96d5b00d98959ea9960f069585ce42b1349a

可以看到我們目錄下有一個名為testfile的文件，內容是Hello Git! 我們使用git hash-object命令將這個文件的內容寫入到 Git 倉庫，-w 選項告訴 Git 把這個內容寫到 Git 的.git/objects對象數據庫目錄，并且 Git 返回了一個 SHA 值，這個 SHA 值就是后續我們要取出這個文件的鍵值：

???Zoker?git:(master)???git?cat-file?-p?9f4d96d5b00d98959ea9960f069585ce42b1349a
Hello?Git

我們使用了git cat-file命令取回剛剛存入到 Git 倉庫的內容，雖然不像 Redis 的命令 get set 那么直觀，但是它確實是一個 KV 數據庫，不是嗎？

我們剛剛嘗試插入的這種數據是基礎的blob類型的對象，Git 還有其它如 tree、commit 等對象類型，這些不同的對象類型之間有特定的關聯關系，它們將不同的對象有邏輯的關聯起來，才能夠幫我們進行不同版本的控制和檢出。稍后會展開講解這幾種不同的對象類型，我們先來了解下 Git 的目錄結構，看看在 Git 中數據是如何存放的。

Git 目錄結構

通過上一節的介紹，我們知道了 Git 本質就是一個 KV 數據庫，而且還提到了內容都是寫到 .git/objects對象目錄，那么這個目錄放在哪里？Git 又是如何存儲這些數據的呢？本節我們重點介紹一下 Git 的存儲目錄結構，了解下 Git 是如何存放不同類型的數據的。

更詳細的介紹參見：https://github.com/git/git/blob/master/Documentation/gitrepository-layout.txt

通過 git init 我們可以在當前目錄初始化一個空的 Git 倉庫，Git 會自動生成 .git 目錄，這個 .git 目錄就是后續所有的 Git 元數據的存儲中心，我們來看一下它的目錄結構：

???Zoker?git?init
Initialized?empty?Git?repository?in?/Users/zoker/tmp/Zoker/.git/
???Zoker?git:(master)???tree?.git
.git
├──?HEAD??????????????//?是一個符號引用，指明當前工作目錄的版本引用信息，我們平時執行?checkout?命令時就會改變?HEAD?的內容
├── config ????????????//?配置當前存儲庫的一些信息，如：Proxy、用戶信息、引用等，此處的配置項相對于全局配置權重更高
├──?description??????//?倉庫描述信息
├──?hooks?????????????//?鉤子目錄，執行?Git?相關命令后的回調腳本，默認會有一些模板
│???├──?update.sample
│???├──?pre-receive.sample
│???└──?...
├──?info????????????????//?存儲一些額外的倉庫信息如?refs、exclude、attributes?等
│???└──?exclude
├──?objects???????????//?元數據存儲中心
│???├──?info
│???└──?pack
└──?refs???????????????//?存放引用信息，也就是分支、標簽
????├──?heads
????└──?tags

默認初始化生成的 Git 倉庫就只有這些文件，除此之外還存在一些其它類型的文件和目錄如packed-refs modules logs等，這些文件都有特定的用途，都是在特定的操作或者配置后才會出現，這里我們只關注核心存儲的實現，這些額外文件或目錄的作用及使用場景再可自行翻閱文檔，這里僅介紹核心的一些文件。

hooks 目錄

hooks 目錄主要存儲的是 Git 鉤子，Git 鉤子可以在很多事件發生后或者發生前觸發，能夠提供給我們非常靈活的使用方式，默認情況下全部都是帶.sample后綴的，需要移除這個后綴并賦予可執行權限方可生效，下面列舉下常用的一些鉤子及其常見的用途：

客戶端鉤子：

pre-commit：提交前觸發，比如檢查提交信息是否規范，測試是否運行完畢，代碼格式是否符合要求
post-commit：相反，這個是整個提交完成后觸發，可以用來發通知

服務端鉤子：

pre-receive：服務端接收推送請求首先被調用的腳本，可以檢測這些被推送的引用是否符合要求
update：與 pre-receive 相似，但是 pre-receive 只會運行一次，而 update 將會為每一個推送的分支分別運行一次
post-receive：整個推送過程完成后觸發，可以用來發送通知、觸發構建系統等

objects 目錄

如上一節我們提到的，Git 將所有接收到的內容生成對象文件存儲在這個目錄下，我們通過 git hash-object 生成了一個對象并寫入了 Git 倉庫，這個對象的鍵值是 9f4d96d5b00d98959ea9960f069585ce42b1349a，這個時候我們來查看下 objects 目錄的結構：

???Zoker?git:(master)???git?hash-object?testfile?-w
9f4d96d5b00d98959ea9960f069585ce42b1349a
???Zoker?git:(master)???tree?.git/objects
.git/objects
├──?9f
│???└──?4d96d5b00d98959ea9960f069585ce42b1349a
├──?info
└──?pack

可以看到 objects 目錄已經有了新的內容，多了一個 9f 的文件夾以及其中的文件，這個文件就是插入到 Git 倉庫的內容的對象文件，Git 取其鍵值的前兩個字母作為文件夾，將后面的字母作為對象文件的文件名進行存儲，這里（也就是objects/[0-9a-f][0-9a-f]）所存儲的對象我們一般稱為 loose objects 或者 unpacked objects，也就是松散對象。

除了對象的存儲文件夾，細心的同學應該已經注意到了 objects/pack 文件夾的存在，這里對應的是打包后的文件，為了節省空間和提升效率，當存儲庫中有過多的松散對象文件或者手動執行 git gc 命令時，亦或是推送拉取的傳輸過程中，Git 都會將這些松散的對象文件打包成pack文件來提升效率，這里存放的就是這些打包后的文件：

???objects?git:(master)?git?gc
...
Compressing?objects:?100%?(75/75),?done.
...
???objects?git:(master)?tree
.
├─?pack
????├──?pack-fe24a22b0313342a6732cff4759bedb25c2ea55d.idx
????└──?pack-fe24a22b0313342a6732cff4759bedb25c2ea55d.pack
└──?...

可以看到 objects 目錄已經沒有了松散對象，取而代之的是 pack 目錄的兩個文件，一個是打包后的文件，另一個是對這個打包的內容進行索引的 idx 文件，方便查詢某個對象是否在這個對應的 pack 包內。

需要注意的是，如果在剛剛我們手動創建的一個 blob 對象的倉庫進行 GC，將不會產生任何效果，因為這個時候整個 Git 倉庫并沒有任何一個引用指向這個對象，我們說這個對象是游離的，下面我們來介紹下存儲引用的目錄。

refs 目錄

refs 目錄存儲我們的引用（references），引用可以看做是對一個版本號的別名，它存儲的實際就是某一個 Commit 的 SHA 值，上面我們用來測試的倉庫并沒有任何一個提交，所以只有一個空的目錄結構。

└──?refs
????├──?heads
????└──?tags

我們隨便找一個包含提交的倉庫查看他的默認分支 master。

???.git?git:(master)?cat?refs/heads/master
87e917616712189ecac8c4890fe7d2dc2d554ac6

可以看到這個master的引用只是存儲了一個 Commit 的 SHA 值，好處當然就是我們不需要記著那長長的一串 SHA 值，我們只需要用master這個別名就可以獲取到這個版本。同樣的 tags 目錄下存儲的就是我們的標簽，與分支不同的是，標簽的所記錄的引用值一般是不會變化的，而分支可以我們的版本變化而變化。除此之外，還可能會看到 refs/remotes refs/fetch 等目錄，這些里面存儲的是特定命名空間的引用。

還有一種情況，就是上面我們講到的 GC 機制，如果一個倉庫執行了 GC，那么不僅objects目錄下的松散對象會被打包，refs下面的引用同樣也會被打包，只不過它存放在裸倉庫的根目錄下 .git/packed-refs

???.git?git:(master)?cat?packed-refs
#?pack-refs?with:?peeled?fully-peeled?sorted
87e917616712189ecac8c4890fe7d2dc2d554ac6?refs/heads/master

當我們需要訪問分支 master 的時候，Git 會首先去 refs/heads 里面進行查找，如果找不到就會前往 .git/packed-refs 進行查找，將所有的引用打包到一個文件無疑提升了不少效率。需要注意的是，如果我們在這個時候往 master 分支上更新了一些提交，這個時候 Git 并不會直接修改 .git/packed-refs文件，它會直接在refs/heads/下重新創建一個master引用，包含最新的提交的 SHA 值，根據剛剛我們介紹的 Git 的機制，Git 會首先在 refs/heads/ 查找，找不到才會去 .git/packed-refs 查找。

那么引用里面存儲的 Commit 的這串 SHA 值到底是指向什么內容呢，我們可以使用之前查看 blob 對象內容的 cat-file 命令進行查看：

???.git?git:(master)?git?cat-file?-p?87e917616712189ecac8c4890fe7d2dc2d554ac6
tree?aab1a9217aa6896ef46d3e1a90bc64e8178e1662?//?指向的?tree?對象
parent?7d000309cb780fa27898b4d103afcfa95a8c04db?//?父提交
author?Zoker?<kaixuanguiqu@gmail.com>?1607958804?+0800?//?作者信息
committer?Zoker?<kaixuanguiqu@gmail.com>?1607958804?+0800?//?提交者信息

test?ssh?//?提交信息

它是一個 commit 類型的對象，主要的屬性是它指向的 tree 對象，它的父提交（如果它是第一個提交，那么這里是 0000000...），以及作者和提交信息。

那么 commit 對象是什么？它所指向的 tree 對象又是什么？與之前我們手工創建的 blob 對象有什么差別？接下來我們來談談 Git 存儲對象。

Git 存儲對象

在 Git 的世界里，一共有四種類型的存儲對象：文件（blob）、樹（tree）、提交（commit）、標簽（tag），這里我們主要探討頭三種類型，因為這三種是最基礎的 Git 元數據，而標簽對象只是一個包含了額外屬性信息的 Tag 而已，也就是附注標簽（annotated tag），這里不再過多的介紹。

輕量標簽（lightweight）與附注標簽（annotated）介紹：https://git-scm.com/book/zh/v2/Git-基礎-打標簽

Blob 對象

在介紹 Git 本質的時候，為了演示 Git 是一個基于內容尋址的 KV 數據庫，我們向 Git 倉庫插入了一個文件的內容：

???Zoker?git:(master)???cat?testfile
Hello?Git
???Zoker?git:(master)???git?hash-object?testfile?-w
9f4d96d5b00d98959ea9960f069585ce42b1349a

這個 Key 為 9f4d96d5b00d98959ea9960f069585ce42b1349a 的 Git 對象實際上就是一個 Blob 對象，他存儲了這個 testfile 文件的值，我們可以使用 cat-file 命令來進行查看：

???Zoker?git:(master)???git?cat-file?-p?9f4d96d5b00d98959ea9960f069585ce42b1349a
Hello?Git

每一次我們修改文件，Git 都會完整的保存一份這個文件的快照而非記錄差異，所以如果我們修改了testfile文件的內容再次存入到 Git 倉庫中的時候，Git 會基于當前最新的內容來生成它的 Key，需要注意的是當內容不變的時候，它的 Key 值是固定的，畢竟我們前面也說了，Git 是一個基于內容尋址的 KV 數據庫。

另外，這里的 Blob 對象存儲的是文本內容，它還可以是二進制內容，但是這里并不建議使用 Git 管理二進制文件的版本。我們 Gitee 平臺在日常運營過程中遇到最多的問題就是用戶倉庫過大，這種情況一般都是用戶提交了大的二進制文件導致的，因為每次文件的變更記錄的是快照，所以這個二進制文件如果變更頻繁，它占用的空間是倍增的。而且對于文本內容的 Blob，Git 在 GC 的過程中會只保存兩次提交之間的文件差異，是可以達到節省空間的效果的，但是對于二進制內容的 Blob 是無法像文本內容的 Blob 那樣處理的，所以盡量不要把頻繁變動的二進制內容存儲到 Git 倉庫，可以使用 LFS 的方式進行存儲。如果已經存在了大量的二進制文件，可以使用filter-branch進行瘦身，新加入的同事在首次 Clone 倉庫的時候肯定會感激你的。

LFS 的使用：https://gitee.com/help/articles/4235，大倉庫的瘦身：https://gitee.com/help/articles/4232，filter-branch：https://github.com/git/git/blob/master/Documentation/git-filter-branch.txt

到了這里是不是覺得哪里不對勁？沒錯，這個 Blob 對象只存儲了這個文件的內容，卻沒有記錄文件名，那我們該怎么知道這個內容是屬于哪個文件的啊？答案是 Git 的另外一個重要的對象：Tree 對象。

Tree 對象

在 Git 中，Tree 對象主要的作用是將多個 Blob 或者子 Tree 對象組織到一起，所有的內容都是通過 Tree 和 Blob 類型的對象進行存儲的。一個 Tree 對象包含了一個或者多個 Tree Entry（樹對象記錄），每個樹對象記錄都包含了一個指向 Blob 或者子 Tree SHA 值的指針，還有它們對應的文件名等信息，其實就可以理解為索引文件系統中的 inode 和 block 的關系，圖示一個 Tree 對象的話，如下圖：

這個 Tree 對象對應的目錄結構就是下面這樣的：

.
├──?LICENSE
├──?readme.md
└──?src
????├──?libssl.so
????└──?logo.png

通過這種方式，我們可以像組織 Linux 下目錄的方式一樣來結構化的存儲我們倉庫的內容，把 Tree 看作目錄結構，把 Blob 看作具體的文件內容。

那么該如何創建一個 Tree 對象呢？在 Git 中是根據暫存區的狀態來創建對應的 Tree 對象的，這里的暫存區其實就是我們日常在使用 Git 的過程中所理解的暫存區（Staged），一般我們使用 git add 命令將某些文件添加到暫存區待提交。在沒有任何提交的空倉庫里，這個暫存區的狀態就是你通過 git add 所添加的那些文件，如：

???Zoker?git:(master)???git?status
On?branch?master

No?commits?yet

Changes?to?be?committed:
??(use?"git?rm?--cached?<file>..."?to?unstage)
????new?file:???LICENSE
????new?file:???readme.md

Untracked?files:
??(use?"git?add?<file>..."?to?include?in?what?will?be?committed)
????src/

這里當前的暫存區狀態就是在根目錄有兩個文件，暫存區的狀態是保存在 .git/index 文件的，我們使用 file 命令來看看它是什么：

???Zoker?git:(master)???file?.git/index
.git/index:?Git?index,?version?2,?2?entries

可以發現在 index 文件中有兩個 entry，也就是根目錄的兩個文件 LICENSE 和 readme.md。對于已經有提交的倉庫，如果暫存區沒有任何內容，那么這個 index 表示的就是當前版本的目錄樹狀態，如果修改或者增刪了文件，并且加入了暫存區，那么 index 就會發生改變，將相關文件的指針指向該文件新的 Blob 對象的 SHA 值。

所以如果想要創建一個 Tree 對象，我們需要往暫存區放點東西，除了使用 git add，我們還可以使用底層命令 update-index 來創建一個暫存區。接下來我們根據上面已經創建好的 testfile 文件來創建一個樹對象，首先就是將文件 testfile 加入到暫存區：

???Zoker?git:(master)???git?update-index?--add?testfile?//?與?git?add?testfile?一樣
???Zoker?git:(master)???git?status
On?branch?master

No?commits?yet

Changes?to?be?committed:
??(use?"git?rm?--cached?<file>..."?to?unstage)
????new?file:???testfile

這個過程 Git 主要是先把testfile的內容以 Blob 的形式插入到 Git 倉庫，然后將返回的這個 Blob 的 SHA 值記錄到index中，告訴暫存區目前這個文件的內容是哪個。

???Zoker?git:(master)???tree?.git/objects
.git/objects
├──?9f
│???└──?4d96d5b00d98959ea9960f069585ce42b1349a
├──?info
└──?pack

3?directories,?1?file
???Zoker?git:(master)???git?cat-file?-p?9f4d96d5b00d98959ea9960f069585ce42b1349a
Hello?Git

Git 在執行update-index命令的時候，把指定文件的內容存儲為 Blob 對象，并且記錄在index文件狀態內。由于在之前我們已經通過 git hash-object 命令將這個文件的內容插入過了，并且我們可以發現因為內容不變，所以生成的這個 Blob 對象的 SHA 值也是一致的，如果像我們這樣已經做過插入的動作，下面的命令是等效的：

git?update-index?--add?--cacheinfo?9f4d96d5b00d98959ea9960f069585ce42b1349a?testfile

這個命令其實就是把之前已經生成的 Blob 對象放到暫存區，并且指定它的文件名字是 testfile。由于我們的暫存區已經有一個文件 testfile，所以我接下來我們可以使用 git write-tree 命令來基于當前暫存區的狀態來創建一個 Tree 對象了：

???Zoker?git:(master)???git?write-tree
aa406ee8804971cf8edfd8c89ff431b0462e250c
???Zoker?git:(master)???tree?.git/objects
.git/objects
├──?9f
│???└──?4d96d5b00d98959ea9960f069585ce42b1349a
├──?aa
│???└──?406ee8804971cf8edfd8c89ff431b0462e250c
├──?info
└──?pack

執行完命令后，Git 會基于當前暫存區的狀態生成一個 SHA 值為aa406ee8804971cf8edfd8c89ff431b0462e250c的 Tree 對象，并把這個 Tree 對象像 Blob 對象一樣存儲在.git/objects目錄下。

???Zoker?git:(master)???git?cat-file?-p?aa406ee8804971cf8edfd8c89ff431b0462e250c
100644?blob?9f4d96d5b00d98959ea9960f069585ce42b1349a????testfile

使用 cat-file 命令查看這個 Tree 對象，可以看到這個對象下只有一個文件，名為testfile。

我們繼續創建第二個 Tree 對象，我們需要第二個 Tree 對象下有修改后的testfile文件，有新增的 testfile2文件，并且需要把第一個 Tree 對象作為第二個 Tree 對象的duplicate目錄。首先我們先把修改后的testfile和新增的testfile2文件加入到暫存區：

???Zoker?git:(master)???git?update-index?testfile
???Zoker?git:(master)???git?update-index?--add?testfile2
???Zoker?git:(master)???git?status
On?branch?master

No?commits?yet

Changes?to?be?committed:
??(use?"git?rm?--cached?<file>..."?to?unstage)
????new?file:???testfile
????new?file:???testfile2

緊接著我們需要把第一個 Tree 對象掛到 duplicate 目錄下，我們可以使用 read-tree 命令來實現：

???Zoker?git:(master)???git?read-tree?--prefix=duplicate?aa406ee8804971cf8edfd8c89ff431b0462e250c?
???Zoker?git:(master)???git?status
On?branch?master

No?commits?yet

Changes?to?be?committed:
??(use?"git?rm?--cached?<file>..."?to?unstage)
????new?file:???duplicate/testfile
????new?file:???testfile
????new?file:???testfile2

然后我們執行 write-tree 并通過 cat-file 查看第二個 Tree 對象：

???Zoker?git:(master)???git?write-tree
64d62cef754e6cc995ed8d34f0d0e233e1dfd5d1
???Zoker?git:(master)???git?cat-file?-p?64d62cef754e6cc995ed8d34f0d0e233e1dfd5d1
040000?tree?aa406ee8804971cf8edfd8c89ff431b0462e250c????duplicate
100644?blob?106287c47fd25ad9a0874670a0d5c6eacf1bfe4e????testfile
100644?blob?098ffe6f84559f4899edf119c25d276dc70607cf????testfile2

成功完成了，我們不僅修改了 testfile 的文件內容，還新增了一個 testfile2 文件，并且還把第一個 Tree 對象當作第二個 Tree 對象的 duplicate 目錄了，這個時候 Tree 對象看起來應該是這樣的：

至此，我們知道了如何手動創建一個 Tree 對象，但是后面如果我需要這兩個不同的 Tree 的快照該怎么辦？總不能都記住這三個 Tree 對象的 SHA 值吧？沒錯，記起來費老大勁了，關鍵是還不知道是誰在什么時間為了什么而創建的這個快照，而 Commit 對象（提交對象）就能夠幫我們解決這個問題。

Commit 對象

Commit 對象主要是為了記錄快照的一些附加信息，并且維護快照之間的線性關系。我們可以通過git commit-tree命令來創建一個提交，這個命令看字面意思就知道，它是用來將 Tree 對象提交為一個 Commit 對象的命令：

???Zoker?git:(master)???git?commit-tree?-h
usage:?git?commit-tree?[(-p?<parent>)...]?[-S[<keyid>]]?[(-m?<message>)...]?[(-F?<file>)...]?<tree>

????-p?<parent>???????????id?of?a?parent?commit?object
????-m?<message>??????????commit?message
????-F?<file>?????????????read?commit?log?message?from?file
????-S,?--gpg-sign[=<key-id>]
??????????????????????????GPG?sign?commit

關鍵的兩個參數是 -p 和 -m，-p 是指定這個提交的父提交，如果是初始的第一個提交，那這里可以忽略；-m 則是指定本次提交的信息，主要是用來描述提交的原因。我們來把第一個 Tree 對象作為我們的初始提交：

???Zoker?git:(master)???git?commit-tree?-m?"init?commit"?aa406ee8804971cf8edfd8c89ff431b0462e250c
17ae181bd6c3e703df7851c0f7ea01d9e33a675b

使用cat-file來查看這個提交：

tree?aa406ee8804971cf8edfd8c89ff431b0462e250c
author?Zoker?<kaixuanguiqu@gmail.com>?1613225370?+0800
committer?Zoker?<kaixuanguiqu@gmail.com>?1613225370?+0800

init?commit

Commit 所存儲的內容是一個 Tree 對象，并且記錄了提交者、提交時間以及提交信息。我們基于這個 Commit 將第二個 Tree 對象作為引用：

???Zoker?git:(master)???git?commit-tree?-p?17ae181bd?-m?"add?dir"?64d62cef754e6cc995ed8d34f0d0e233e1dfd5d1
de96a74725dd72c10693c4896cb74e8967859e58
???Zoker?git:(master)???git?cat-file?-p?de96a74725dd72c10693c4896cb74e8967859e58
tree?64d62cef754e6cc995ed8d34f0d0e233e1dfd5d1
parent?17ae181bd6c3e703df7851c0f7ea01d9e33a675b
author?Zoker?<kaixuanguiqu@gmail.com>?1613225850?+0800
committer?Zoker?<kaixuanguiqu@gmail.com>?1613225850?+0800

add?dir

我們可以使用 git log 來查看這兩個提交，這里添加 --stat 參數查看文件變更記錄：

commit?de96a74725dd72c10693c4896cb74e8967859e58
Author:?Zoker?<kaixuanguiqu@gmail.com>
Date:???Sun?Feb?13?22:17:30?2021?+0800

????add?dir

?duplicate/testfile?|?1?+
?testfile???????????|?2?+-
?testfile2??????????|?1?+
?3?files?changed,?3?insertions(+),?1?deletion(-)

commit?17ae181bd6c3e703df7851c0f7ea01d9e33a675b
Author:?Zoker?<kaixuanguiqu@gmail.com>
Date:???Sun?Feb?13?22:09:30?2021?+0800

????init?commit

?testfile?|?1?+
?1?file?changed,?1?insertion(+)

這個時候整個對象的結構如下圖：

練習：使用底層命令創建一個提交

僅使用我們上面提到的hash-object write-tree read-tree commit-tree等底層命令來創建一個提交，思考哪些過程是與git add git commit等價的。

對象存儲方式

我們通過前面的介紹，知道了 Git 是將數據以不同的對象類型歸納，并且根據內容計算出一個 SHA 值用來作為尋址，那么到底是如何計算的呢？以 Blob 對象為例，Git 主要是做了如下幾步：

識別對象的類型，構造頭部信息，以類型 + 內容字節數 + 空字節作為頭部信息如 blob 151\u0000
將頭部信息與內容拼接，并且計算 SHA-1 校驗和
通過 zlib 壓縮內容
通過 SHA 值將其內容放到對應的 objects 目錄

整個過程就做了這些事情，Tree 對象和 Commit 對象也差不多，只是頭部類型有所差異而已，這里不再贅述，《Pro Git 2》在 Git 內部原理章節中有介紹如何使用 Ruby 來實現同等的邏輯，感興趣的可以自行翻閱。

Git-內部原理：https://git-scm.com/book/zh/v2/Git-內部原理-Git-對象

Git 引用

我們在上面通過 git log --stat 17ae181b 能夠查看第一個版本的相關信息，并且可以通過這串 SHA 值拿到這個快照的內容，但是還是挺麻煩的，因為我們要記住一串毫無意義的字符串，這個時候 Git 的引用就派上用場了，在 Git 目錄結構章節我們已經介紹了refs目錄，我們知道在引用中存儲的就是 Commit 對象的鍵值，也就是這個對象的 SHA 值，既然如此，我們就給我們當前的版本起一個有意義的名字，一般我們會拿master作為默認分支引用：

???Zoker?git:(master)???echo?"17ae181bd6c3e703df7851c0f7ea01d9e33a675b"?>>?.git/refs/heads/master
???Zoker?git:(master)???tree?.git/refs
.git/refs
├──?heads
│???└──?master
└──?tags

這個時候，master 里面存儲了我們的第一個 Commit 的 SHA 值，我們可以使用 master 來代替 17ae181b 這串毫無意義的字符串了。

???Zoker?git:(master)???git?cat-file?-p?master
tree?aa406ee8804971cf8edfd8c89ff431b0462e250c
author?Zoker?<kaixuanguiqu@gmail.com>?1613916447?+0800
committer?Zoker?<kaixuanguiqu@gmail.com>?1613916447?+0800

init?commit

但是，這個并不是我們最新的版本，我們最新的版本是第二個提交 de96a74725dd72c10693c4896cb74e8967859e58，同樣的，我們可以把refs/heads/master的內容更改為這個提交的 SHA 值，但是這里我們使用一個底層命令來完成。

???Zoker?git:(master)???git?update-ref?refs/heads/master?de96a74725dd72c10693c4896cb74e8967859e58
???Zoker?git:(master)???cat?.git/refs/heads/master
de96a74725dd72c10693c4896cb74e8967859e58

這個時候，分支 master 就指向了我們最新的版本。