深入理解 Git

Git 使我們?nèi)粘Ｊ褂玫拈_發(fā)工具，用于代碼的版本管理，但是我們常用的各種命令 git add, git commit, git push, git pull 等等究竟是啥樣子，帶著好奇心，趁著空重新讀了下 Git 的官方文檔。發(fā)現(xiàn)了一些除了剛剛提到的高級命令以外的低級命令，以及 Git 究竟是如何運轉(zhuǎn)的。（當(dāng)然不是源碼解讀）

基本概念

git 對于文件的存儲位置進行了3層分割，用于不同狀態(tài)下的文件。我們可以理解為3個箱子。

• Work Directory
• Index/Stage
• Git Directory

Work Directory（俗稱工作區(qū)）

工作區(qū)就是我們文件正常編輯的地方，我們在這進行代碼的編寫。當(dāng)我們完成之后，我們會發(fā)現(xiàn)我的的 cli 會提示我們這些文件被修改，從而方便我們區(qū)分哪些文件被修改了，哪些沒有被修改。

Index/Stage（暫存區(qū)）

暫存區(qū)就是我們在執(zhí)行了 git add 之后，文件存放的地方，說明這些文件準(zhǔn)備進行提交了。之所以有這么個地方，就是能夠?qū)⑿枰峤坏膬?nèi)容進行一次性提交，從而避免了每次提交都存在歧義的情況。同時也方便我們對將要提交的地方進行調(diào)整。

Git Directory

Git 的區(qū)域，用于將歷史記錄進行統(tǒng)一的進行管理。方便后續(xù)迭代的時候進行一定的調(diào)整。git 中使用文件的形式進行管理。

前面所說可能比較抽象，用一個簡單的話來說，當(dāng)我們大腦中有一個好的 idea 的時候，我們的大腦就是一個 work directory，這個時候為了避免忘記，或者它丟失，我們需要將他用筆寫下來，這個時候紙就是 Index/Stage。同時我們會進行不斷的思考，那么就是不斷的修改 work directory 的內(nèi)容，并不斷 add 到 Index/Stage 當(dāng)中。當(dāng)這個 idea 整理清楚的時候，我們需要將這張紙整理起來，就像是放到檔案室，這個時候檔案室就是我們的 Git Directory。

Git 基本對象

說完這些，就可以進入我們的正題了。

Git 實際上有自己對于對象的定義。 Git 當(dāng)中存在 3種對象，blob，tree，commit。而所有對象都有自己的身份標(biāo)記 —— SHA-1碼。（對于 SHA-1 的解釋可以參見維基百科）

blob

blob 就是我們所說的簡單文件，在谷歌中的翻譯 blob 指的是大的二進制文件。在 git 中你可以認(rèn)為他就是文件對象。

tree

既然有了文件對象，那么需要對于文件對象進行層級排列。這個時候就需要引入 tree 的概念了。Git 模仿了 Unix 的文件管理體系，不過他沒有系統(tǒng)的那么沉重，相對而言更加輕量級，僅僅包含了里面有哪些文件。

commit

當(dāng)文件結(jié)構(gòu)已經(jīng)確定了，剩下的就是將這些內(nèi)容進行提交了。每次當(dāng)我們將 tree 提交的時候，就創(chuàng)建了一個 commit，而有 SHA-1 的 commit 便決定了 Git 的整個體系，能夠通過 SHA-1 進行追蹤。

在清楚了上面的幾個關(guān)鍵點之后，就可以進入我們的正題了。從我們創(chuàng)建 git 到提交完成整個工程，具體發(fā)生了些什么。

深入理解 Git

創(chuàng)建 git

當(dāng)我們完成了 git init 之后，我們創(chuàng)建了一個包含了 .git 的文件目錄

? test git:(master) la total 0 drwxr-xr-x 10 zkhcreator staff 320B Jan 31 18:40 .git 復(fù)制代碼

這個時候我們會發(fā)現(xiàn) .git 文件下的結(jié)構(gòu)如下：（附帶功能描述）

.git ├── HEAD （用于管理 HEAD 所在的位置） ├── branches （有哪些分支） ├── config （配置文件） ├── description （對于這個工程的描述文件） ├── hooks (本地的 git 的所有鉤子的配置) │?? ├── applypatch-msg.sample │?? ├── commit-msg.sample │?? ├── fsmonitor-watchman.sample │?? ├── post-update.sample │?? ├── pre-applypatch.sample │?? ├── pre-commit.sample │?? ├── pre-push.sample │?? ├── pre-rebase.sample │?? ├── pre-receive.sample │?? ├── prepare-commit-msg.sample │?? └── update.sample ├── info │?? └── exclude (用于在 git 層面告知 git 哪些文件不需要進行版本控制) ├── objects (所有 git 對象) │?? ├── info （git 對象的信息，對象以及他的 SHA-1 存儲的地方） │?? └── pack （git 執(zhí)行 gc 操作打包后的存儲地） └── refs （所有引用(references)的地方）├── heads （所有分支頭所在的位置）└── tags （所有標(biāo)簽所在的位置） 復(fù)制代碼

上圖的文件樹結(jié)構(gòu)構(gòu)成了一個簡單的 git

創(chuàng)建 blob

按照往常的思路，我們需要創(chuàng)建文件并執(zhí)行 git add filename 但是這里我們不用這些高級命令，轉(zhuǎn)而使用低級命令。

首先我們創(chuàng)建一個文件 echo 'test1' | git hash-object -w --stdin 這樣就創(chuàng)建完成了一個文件，其中 -w 直接將數(shù)據(jù)寫入數(shù)據(jù)庫（準(zhǔn)確的說是文件當(dāng)中，因為 git 沒有數(shù)據(jù)庫這個概念，都是以文件進行存儲的）當(dāng)中，--stdin 表示使用標(biāo)準(zhǔn)輸入輸出數(shù)據(jù)流格式進行讀取。

此時我們會發(fā)現(xiàn)他返回了一條 SHA-1: a5bce3fd2565d8f458555a0c6f42d0504a848bd5，同時再次打印我們 .git 中的文件路徑，我們會發(fā)現(xiàn)他的 objects 路徑下多了 a5/bce3fd2565d8f458555a0c6f42d0504a848bd5 這樣的一個文件，這個和生成的 SHA-1 有一些微妙的聯(lián)系，實際上 git 取了 git 的前兩位作為一級目錄，并將后面的位數(shù)作為文件名。

如果我們嘗試去打開這個文件，我們會發(fā)現(xiàn)他是一堆亂碼，因為 git 已經(jīng)幫我轉(zhuǎn)我一次了，如果需要讀取里面的內(nèi)容，我們需要使用 git cat-file -p a5bce3fd2565d8f458555a0c6f42d0504a848bd5 去進行展示，很明顯，他就會輸出我們剛剛通過數(shù)據(jù)流輸入輸出的 test1。上面命令中的 git cat-file -p 就是用來打印 SHA-1 對象的實際內(nèi)容。

有人可能會說，我們 git 不都是添加文件的么？你這樣直接寫數(shù)據(jù)庫算什么？

那我們來新建一個文件來重復(fù)以上操作。我們執(zhí)行以下命令

$ echo "version 1" > just_for_test.txt $ git hash-object -w just_for_test.txt 83baae61804e65cc73a7201a7252750c76066a30 復(fù)制代碼

這個時候我們發(fā)現(xiàn)又多了一個文件 .git/objects/83/baae61804e65cc73a7201a7252750c76066a30，然后我們再執(zhí)行一次寫入操作，嘗試去修改里面的內(nèi)容

echo "version 2" > just_for_test.txt git hash-object -w just_for_test.txt 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a 復(fù)制代碼

這個時候我們會發(fā)現(xiàn)，結(jié)構(gòu)路徑除了我們剛剛生成的 83baae61(為了方便理解，取前幾位)，還有一條新的 .git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a。很明顯，文件更新的情況，已經(jīng)被寫入到 git 的文件中。

但是我們執(zhí)行 git status 會發(fā)現(xiàn)，文件還沒有提交，說明 git 在添加到 commit 前，會將文件進行緩存。（不過什么時候進行存儲數(shù)據(jù)庫的，可能需要看下源碼）

既然已經(jīng)有了 sha-1 并且我們已經(jīng)將文件存儲到數(shù)據(jù)庫，這個時候我們做數(shù)據(jù)恢復(fù)操作就很簡單了。只需要執(zhí)行 git cat-file -p 83baae61804e65cc73a7201a7252750c76066a30 > test.txt 即可將前面的 version 1 恢復(fù)到文件目錄當(dāng)中。

這個時候如果我們重新執(zhí)行 git has-object -w just_for_test.txt 我們會發(fā)現(xiàn)目錄結(jié)構(gòu)沒有發(fā)生改變，因為 git 對于文件進行存儲是基于文件內(nèi)部的內(nèi)容的，和其他的東西并無關(guān)系。

前面提到，git 當(dāng)中總共有3種類型，但是 SHA-1 是通的，所以，有時候我們需要確認(rèn)對應(yīng)的 SHA-1 是什么類型，我們就可以使用 git cat-file -t SHA-1 進行打印，很明顯，這個文件是 blob 對象。

創(chuàng)建 tree

如果單純的文件，肯定是不能構(gòu)成樹目錄的，就像我們腦子中的點子，順序很亂，只有當(dāng)我們寫下來的時候，才能將它的順序理清楚。所以只有當(dāng)需要提交到 stash 才能確定誰再哪。

那么我們需要首先給文件提供一個暫存，故需要執(zhí)行 git update-index --add --cacheinfo 100644 83baae61804e65cc73a7201a7252750c76066a30 just_for_test.txt 將在數(shù)據(jù)庫當(dāng)中指定的文件進行存儲到暫存區(qū)。--add 標(biāo)識將工作區(qū)域的文件注冊到暫存區(qū)當(dāng)中，但是如果已經(jīng)添加，則不會重復(fù)添加。--cacheinfo 標(biāo)識需要添加的數(shù)據(jù)的詳細信息，比如說添加指定文件，以及他們的權(quán)限。**其中的文件名是放到緩存中的文件名，一般我們通過 add 進去的 work directory 和 stage 是一致的，但是可以手動指定不同，SHA-1 用來確定文件的內(nèi)容具體是啥。**此時我們執(zhí)行 git status 會發(fā)現(xiàn)，文件已經(jīng)被添加到暫存區(qū)了。

然后通過 git write-tree 將當(dāng)前暫存區(qū)域的對象寫到樹對象當(dāng)中。這個時候我們會發(fā)現(xiàn)它又給了我們一個 SHA-1：ffb66e4709bf8e9c0b101e63c6dbea3780293ff3 這個是生成的樹對象的標(biāo)識符，我們可以通過 git cat-file -t SHA-1 來獲得它的類型就是我們想要的 tree。 當(dāng)然通過搜索 $ find .git/objects/ff 也能在 objects 中很容易找到我們需要的文件。

那么樹對象能進行嵌套么？答案當(dāng)然是肯定的。

我們可以通過 git read-tree --prefix=bak ffb66e4709bf8e9c0b101e63c6dbea3780293ff3 來將原有的 tree 進行備份到當(dāng)前的 tree 下面，由于老的 tree 是 object 對象，所以當(dāng)你讀取出來之后，你在 git status 下你會發(fā)現(xiàn)他被寫入暫存區(qū)了，但是在 work directory 當(dāng)中是需要刪除的，也就是這個文件本身是不存在的，這都是因為無中生有，或者說強制讀取對象的造成的。

創(chuàng)建 commit

既然完成了 stage 的寫入，最后一步就是需要將當(dāng)前的 tree 進行提交，并創(chuàng)建提交對象。這時候只需要執(zhí)行 echo "first commit" | git commit-tree f9b1ec32e2c3b591a72aeec583da3dced8eaa2aa 這個時候，我們通過 git log 會發(fā)現(xiàn)，我們已經(jīng)提交了 commit。但是 git status 還是有文件沒有更新。這個原因也很簡單，就是因為我們沒有創(chuàng)建分支，這就導(dǎo)致 commit 不知道該提交到哪里。 只需要 git branch new_branch_name $(echo "commit message" | git commit-tree f9b1ec32e2c3b591a72aeec583da3dced8eaa2aa) 即可。

最后

當(dāng)我們提交完上面的操作之后，也就是完成了我們最基本的常用命令的底層的操作。這個時候我們重新打印下我們的 .git 文件。會發(fā)現(xiàn)里面多了好多東西，除了我們自己的 objects 還有很多剛剛注釋里面提到的，但是文章當(dāng)中沒有提到的內(nèi)容。 比如說:

• COMMIT_EDITMSG：最近一次 commit 的內(nèi)容
• HEAD：當(dāng)前的頭的位置，ref: refs/heads/master 即引用的位置為 refs/heads/master 文件夾中的內(nèi)容。
• INDEX：放置過 index 之后，即執(zhí)行 git update-index 之后 index 的內(nèi)容，編碼過后的文件，不能容易的看懂。
• logs/HEAD：HEAD 切換的日志文件。
• logs/refs/heads/master： master 的 git 修改日志情況。左邊為 0，右邊有值壽命這個是新添加的。相反右邊為 0說明文件是移除的。同時數(shù)字前4位標(biāo)識所有內(nèi)容長度的十六進制數(shù)，主要方便上傳下載的智能協(xié)議的同步操作。具體內(nèi)容可見 Git 傳輸協(xié)議

0000000000000000000000000000000000000000 d6f0ab93a960f0aa1127ce4a3cf2fb00c5cee78f zkhCreator <zkhCreator@gmail.com> 1548937962 +0800 commit (initial): test d6f0ab93a960f0aa1127ce4a3cf2fb00c5cee78f b6542b871b52bdf66481d03127620e1d7b7d37c9 zkhCreator <zkhCreator@gmail.com> 1548938032 +0800 commit: test2 復(fù)制代碼

• refs/heads/master：當(dāng)前這個 master 對應(yīng)的提交對象的 SHA-1 值。
• refs/tags：對應(yīng) tag 的指向的提交對象的 SHA-1 值存儲的地方。

最后的最后

當(dāng)然其中還存在 objects/info 和 objects/pack 這兩個。你可以嘗試在工程中執(zhí)行 git gc 來對當(dāng)前內(nèi)容進行整理。你會發(fā)現(xiàn)文件當(dāng)中的 objects/ 目錄下干凈了很多，僅僅留下了 objects/info/packs 和 objects/pack 。這個時候?qū)嶋H上 git 將你的文件進行了打包操作，從而減少了整個工程的體積。路徑中的 pack-SHA1.idx 就是這個包的索引，里面包含了打包之后的文件信息（主要用于上傳下載的過程中的不常用的文件索引，可以通過 git verify-pack -v .git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.idx 進行查看文件目錄），pack-SHA1.pack 則是壓縮的 git 對象的集合。對于細節(jié)想了解的同學(xué)可以查看官網(wǎng)的Git 內(nèi)部文件。

總結(jié)

以上是生活随笔為你收集整理的深入理解 Git的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。