簡單地說，Git 究竟是怎樣的一個系統呢？請注意接下來的內容非常重要，若你理解了 Git 的思想和基本工作原理，用起來就會知其所以然，游刃有余。

在學習 Git 時，請盡量理清你對其它版本管理系統已有的認識，如 CVS、Subversion 或 Perforce， 這樣能幫助你使用工具時避免發生混淆。

盡管 Git 用起來與其它的版本控制系統非常相似， 但它在對信息的存儲和認知方式上卻有很大差異，理解這些差異將有助于避免使用中的困惑。

Git 初始化代碼倉庫

執行完成了 git init 命令，究竟做了什么呢？

執行完成如下命令之后，我們可以得到下圖所示的內容，右側的就是 Git 為我們創建的代碼倉庫，其中包含了用于版本管理所需要的內容。

# 左邊執行
$ mkdir git-demo
$ cd git-demo && git init
$ rm -rf .git/hooks/*.sample

# 右邊執行
$ watch -n 1 -d find .

我們這里可以一起看下生成的 .git 目錄的結構如何：

? tree .git
.git
├── HEAD
├── config
├── description
├── hooks
├── info
│ └── exclude
├── objects
│ ├── info
│ └── pack
└── refs
├── heads
└── tags

.git/config - 當前代碼倉庫本地的配置文件

• 本地配置文件（.git/config）和全局配置文件（~/.gitconfig）
• 通過執行如下命令，可以將用戶配置記錄到本地代碼倉庫的配置文件中去
• git config user.name "demo"
• git config user.email "demo@demo.com"

? cat .git/config
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true

[user]
    name = demo
    email = demo@demo.com

.git/objects - 當前代碼倉庫代碼的存儲位置

• blob 類型
• commit 類型
• tree 類型

# 均無內容
? ll .git/objects
total 0
drwxr-xr-x 2 escape staff 64B Nov 23 20:39 info
drwxr-xr-x 2 escape staff 64B Nov 23 20:39 pack

? ll .git/objects/info
? ll .git/objects/pack

.git/info - 當前倉庫的排除等信息

? cat ./.git/info/exclude
# git ls-files --others --exclude-from=.git/info/exclude
# Lines that start with '#' are comments.
# For a project mostly in C, the following would be a good set of
# exclude patterns (uncomment them if you want to use them):
# *.[oa]
# *~

.git/hooks - 當前代碼倉庫默認鉤子腳本

./.git/hooks/commit-msg.sample
./.git/hooks/pre-rebase.sample
./.git/hooks/pre-commit.sample
./.git/hooks/applypatch-msg.sample
./.git/hooks/fsmonitor-watchman.sample
./.git/hooks/pre-receive.sample
./.git/hooks/prepare-commit-msg.sample
./.git/hooks/post-update.sample
./.git/hooks/pre-merge-commit.sample
./.git/hooks/pre-applypatch.sample
./.git/hooks/pre-push.sample
./.git/hooks/update.sample

.git/HEAD - 當前代碼倉庫的分支指針

? cat .git/HEAD
ref: refs/heads/master

.git/refs - 當前代碼倉庫的頭指針

# 均無內容
? ll .git/refs
total 0
drwxr-xr-x 2 escape staff 64B Nov 23 20:39 heads
drwxr-xr-x 2 escape staff 64B Nov 23 20:39 tags

? ll .git/refs/heads
? ll .git/refs/tags

.git/description - 當前代碼倉庫的描述信息

? cat .git/description
Unnamed repository; edit this file 'description' to name the repository.

add 之后發生了什么

執行完成了 git add 命令，究竟做了什么呢？

執行完成如下命令之后，我們可以得到下圖所示的內容，我們發現右側新增了一個文件，但是 Git 目錄里面的內容絲毫沒有變化。這是因為，我們現在執行的修改默認是放在工作區的，而工作區里面的修改不歸 Git 目錄去管理。

而當我們執行 git status 命令的時候，Git 又可以識別出來現在工作區新增了一個文件，這里怎么做到的呢？—— 詳見[理解 blob 對象和 SHA1]部分

而當我們執行 git add 命令讓 Git 幫助我們管理文件的時候，發現右側新增了一個目錄和兩個文件，分別是 8d 目錄、index 和 0e41.. 文件。

# 左邊執行
$ echo "hello git" > helle.txt
$ git status
$ git add hello.txt

# 右邊執行
$ watch -n 1 -d find .

我們這里重點看下，生成的 8d 這個目錄以及下面的文件。而其名稱的由來是因為 Git 對其進行了一個叫做 SHA1 的 Hash 算法，用于將文件內容或者字符串變成這么一串加密的字符。

# 查看 objects 的文件類型
$ git cat-file -t 8d0e41
blob

# 查看 objects 的文件內容
$ git cat-file -p 8d0e41
hello git

# 查看 objects 的文件大小
$ git cat-file -s 8d0e41
10

# 拼裝起來
blob 10\\0hello git

現在我們就知道了，執行 git add 命令將文件從工作區添加到暫存區里面，Git 會把幫助我們生成一些 Git 的對象，它存儲的是文件的內容和文件類型并不存儲文件名稱。

微信搜索公眾號：架構師指南，回復：架構師 領取資料 。

為了驗證我們上述的說法，我們可以添加同樣的內容到另一個文件，然后進行提交，來觀察 .git 目錄的變化。我們發現，右側的 objects 目錄并沒有新增目錄和文件。這就可以證明，blob 類型的 object 只存儲的是文件的內容，如果兩個文件的內容一致的話，則只需要存儲一個 object 即可。

話說這里 object 為什么沒有存儲文件名稱呢？這里因為 SHA1 的 Hash 算法計算哈希的時候，本身就不包括文件名稱，所以取什么名稱都是無所謂的。那問題來了，就是文件名的信息都存儲到哪里去了呢？—— 詳見[理解 blob 對象和 SHA1]部分

# 左邊執行
$ echo "hello git" > tmp.txt
$ git add tmp.txt

# 右邊執行
$ watch -n 1 -d find .

理解 blob 對象和 SHA1

了解 Git 的 blob 對象和 SHA1 之前的關系和對應計算！

Hash 算法是把任意長度的輸入通過散列算法變化成固定長度的輸出，根據算法的不同，生成的長度也有所不同。

Hash 算法：

• MD5 - 128bit - 不安全 - 文件校驗
• SHA1 - 160bit(40位) - 不安全 - Git 存儲
• SHA256 - 256bit- 安全 - Docker 鏡像
• SHA512 - 512bit - 安全

但是，當我們使用工具對上述文件內容進行 SHA1 計算的時候，會發現并沒有我們在 .git 目錄里面看到的那樣，這是為什么呢？

? echo "hello git" | shasum
d6a96ae3b442218a91512b9e1c57b9578b487a0b -

這里因為 Git 工具的計算方式，是使用類型 長度 \\0 內容的方式進行計算的。這里，我們算了下文件內容只有九位，但是這里是十位，這里因為內容里面有換行符的存在導致的。現在我們就可以使用 git cat-file 命令來拼裝 Git 工具存儲的完整內容了。

? ls -lh hello.txt
-rw-r--r-- 1 escape staff 10B Nov 23 21:12 hello.txt

? echo "blob 10\\0hello git" | shasum
8d0e41234f24b6da002d962a26c2495ea16a425f -

# 拼裝起來
blob 10\\0hello git

當我們使用 cat 命令來查看 object 對象里面的內容的時候，發現看著像是一串亂碼。其實這是 Git 工具將文件的原始內容進行一個壓縮，然后再存儲到 object 對象里面。奇怪的是，我們發現壓縮之后的內容反而比原始內容還大！

這是因為其進行了壓縮，存儲了一些壓縮相關的信息。上例所示的比原始文件大，是因為我們創建的內容實在是太小了。當我們常見一個比較大的文件時，就會看到壓縮之后的文件大小遠小于原始文件的。

? cat .git/objects/8d/0e41234f24b6da002d962a26c2495ea16a425f
xKOR04`HWH,6A%

? ls -lh .git/objects/8d/0e41234f24b6da002d962a26c2495ea16a425f
-r--r--r-- 1 escape staff 26B Nov 23 21:36 .git/objects/8d/0e41234f24b6da002d962a26c2495ea16a425f

? file .git/objects/8d/0e41234f24b6da002d962a26c2495ea16a425f
.git/objects/8d/0e41234f24b6da002d962a26c2495ea16a425f: VAX COFF executable not stripped - version 16694

其實，我們這里也是可以通過 Python 代碼來獲取二進制 object 對象的內容的。

import zlib

contents = open('0e41234f24b6da002d962a26c2495ea16a425f', 'rb').read()
zlib.decompress(contents)

聊聊工作區和暫存區

聊聊工作區和暫存區，以及文件如何在工作區和緩存區之間同步的問題。

之前的章節我們也聊到了，當我們執行 git status 命令的時候，Git 工具怎么知道我們有一個文件沒有追蹤，以及文件名的信息都存儲到哪里去了？

這一切的答案，都要從工作區和索引區講起。Git 根據其存儲的狀態不同，將對應狀態的“空間”分為工作區、暫存區（也可稱為索引區）和版本區三類。具體示例，可以參考下圖。

而更加深層次的理解，就要從執行 git add 命令后生成相關的 object 對象，但是其存儲的是文件的類容、大小和內容，并不包含文件名稱的信息。而文件名稱相關的信息就包含在生成的 index 文件（索引文件）里面。

當我們直接查看 index 文件里面的內容，發現使我們無法理解的亂碼，但是通過基本的輸出，我們可以看到其文件名稱。要想查看 index 文件的內容，可以通過 Git 提供的相關命令進行查看。

# 左邊執行
$ echo "file1" > file1.txt
$ git add file1.txt
$ cat .git/index

$ git ls-files # 列出當前暫存區的文件列表信息
$ git ls-files -s # 列出當前暫存區文件的詳細信息

# 右邊執行
$ watch -n 1 -d tree .git

當添加文件的時候，文件或目錄會從工作區流向暫存區，加之一些其他操作，會導致工作區和暫存區是會有一定差別的。這就會導致，當我們執行 git status 的結果就是兩者的差別。

經過如下操作，會使工作區和暫存區和的內容不一致了，通過命令我們也是可以查看區別的。當我們使用 add 命令將新文件添加到暫存區的時候，會發現這下就一致了。

# 左邊執行
$ git status
$ echo "file2" > file2.txt
$ git ls-files -s
$ git status
$ git add file2.txt
$ git ls-files -s
$ git status

# 右邊執行
$ watch -n 1 -d tree .git

如果我們這里去修改一個文件的話，很顯然這個時候我們的工作區和暫存區又不一致了。當我們使用命令去查看文件狀態的時候，發現一個文件被修改了，而 Git 是怎么知道的呢？咳咳，就是通過查找 index 文件的內容，找到對應文件名稱以及其內部引用的 object 對象，與工作區的文件內容進行對比而來的。

# 左邊執行
$ git ls-files -s
$ echo "file.txt" > file1.txt
$ git status

# 右邊執行
$ watch -n 1 -d tree .git

而這個時候，我們再使用 git add 命令將其修改內容保存至暫存區的話，會發現對應文件的 object 的 blob 對象的引用值發生改變了。這時可以發現，objects 目錄下面有三個對象了，其中 file1.txt 占了兩個，但是文件卻只有兩個。通過命令查看對應 blob 對象的內容，發現各有不同。

# 左邊執行
$ git ls-files -s
$ git add file1.txt
$ git ls-files -s

# 右邊執行
$ watch -n 1 -d tree .git

理解 commit 提交原理

執行完成了 git commit 命令，究竟做了什么呢？

Git 倉庫中的提交記錄保存的是你的目錄下所有文件的快照，就像是把整個目錄復制，然后再粘貼一樣，但比復制粘貼優雅許多！Git 希望提交記錄盡可能地輕量，因此在你每次進行提交時，它并不會盲目地復制整個目錄。條件允許的情況下，它會將當前版本與倉庫中的上一個版本進行對比，并把所有的差異打包到一起作為一個提交記錄。Git 還保存了提交的歷史記錄。這也是為什么大多數提交記錄的上面都有父節點的原因。

當我們使用 add 命令將工作區提交到暫存區，而暫存區其實保存的是當前文件的一個狀態，其中包括有哪些目錄和文件，以及其對應的大小和內容等信息。但是我們最終是需要將其提交到代碼倉庫（本地）的，而其命令就是 git commit 了。

而當我們執行 git commit 命令的時候，究竟都發生了什么呢？可以看到當提交之后，.git 目錄中生成了兩個信息的 object 對象，其中 logs 和 refs 目錄都有新的文件生成。通過如下操作，我們可以查看到其提交的類型和對應內容。

# 左邊執行
$ git commit -m "1st commit"

$ git cat-file -t 6e4a700 # 查看 commit 對象的類型
$ git cat-file -p 6e4a700 # 查看 commit 對象的內容

$ git cat-file -t 64d6ef5 # 查看 tree 對象的類型
$ git cat-file -p 64d6ef5 # 查看 tree 對象的內容

# 右邊執行
$ watch -n 1 -d tree .git

這樣我們就理解了，當我們執行 git commit 命令之后，會生成一個 commit 對象和一個 tree 對象。commit 對象內容里面包含了一個 tree 對象和相關提交信息，而 tree 對象里面則包含了這次我們提交版本里面的文件狀態（文件名稱和 blob 對象），這樣我們就知道了這次提交的變動了。

我們這次提交之后，處理 objects 目錄發生變動之外，還有一些其他的變化。比如 logs 和 refs 的目錄有所變化。我們查看 refs 目錄里面的內容，發現其指向了 6e4a70 這個 commit 對象，即當前 master 分支上面最新的提交就是這個 6e4a70 了。

而這個 6e4a70 這個 commit 對象，有一個 HEAD 的指向，就是 .git 目錄下的 HEAD 文件。其實質就是一個指針，其永遠指向我們當前工作的分支，即這里我們工作在 master 分支上。當我們切換分支的時候，這個文件的指向也會隨機改變的。

# 左邊執行
$ cat .git/refs/heads/master
$ cat .git/HEAD

# 右邊執行
$ watch -n 1 -d tree .git