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
.git/HEAD .git/config .git/objects .git/objects/info .git/objects/pack .git/refs .git/refs/heads .git/refs/tags .git/hooks .git/hooks/commit-msg.sample .git/hooks/post-update.sample .git/hooks/update.sample .git/hooks/pre-rebase.sample .git/hooks/pre-applypatch.sample .git/hooks/fsmonitor-watchman.sample .git/hooks/applypatch-msg.sample .git/hooks/pre-receive.sample .git/hooks/pre-push.sample .git/hooks/prepare-commit-msg.sample .git/hooks/pre-commit.sample .git/info .git/info/exclude .git/branches .git/description |
我們發現，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/83/baae61804e65cc73a7201a7252750c76066a30 |
我們發現，.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
version 2
$ git cat-file -p 83baa > file.txt
$ cat file.txt
version 1 |
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 author john <john@163.com> 1537961478 +0800 committer john <john@163.com> 1537961478 +0800 first commit |
在git commit-tree命令中，-m選項用於指定本次提交的注釋。
我們可以很清楚的看到，一個提交對象包含着所提交版本的樹對象hash鍵值，author和commiter，以及修改和提交的時間，最后是本次提交的注釋。
其中committer和author是通過git config命令設置的。
接下來，修改某個文件，重新創建一個樹對象，並將這一樹對象提交，作為項目的第二個提交版本。執行
|
$ echo "new version" > file.txt
$ git update-index file.txt
$ git write-tree
848e967643b947124acacc3a2d6c5a13c549231c $ git commit-tree 848e96 -p 7020a97 -m "second commit" e838c8678ef789df84c2666495663060c90975d7 $ git cat-file -p e838c tree 848e967643b947124acacc3a2d6c5a13c549231c parent 7020a97c0e792f340e00e1bb8edcbafcc4dfb60f author john <john@163.com> 1537962442 +0800 committer john <john@163.com> 1537962442 +0800 second commit |
我們可以按照上述步驟，再提交第三個版本。
| $ 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 <john@163.com> 1537963274 +0800 committer john <john@163.com> 1537963274 +0800
third commit
|
提交完三個版本，我們通過git log 查看最近一個提交對象的提交記錄
| $ git log 49140 commit 491404fa6e6f95eb14683c3c06d10ddc5f8e883f Author: john <john@163.com> Date: Wed Sep 26 20:01:14 2018 +0800 third commit commit e838c8678ef789df84c2666495663060c90975d7 Author: john <john@163.com> Date: Wed Sep 26 19:47:22 2018 +0800 second commit commit 7020a97c0e792f340e00e1bb8edcbafcc4dfb60f Author: john <john@163.com> 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 <john@163.com> Date: Wed Sep 26 20:01:14 2018 +0800
third commit
commit e838c8678ef789df84c2666495663060c90975d7
Author: john <john@163.com> Date: Wed Sep 26 19:47:22 2018 +0800
second commit
commit 7020a97c0e792f340e00e1bb8edcbafcc4dfb60f
Author: john <john@163.com> Date: Wed Sep 26 19:31:18 2018 +0800
first commit
$ git log master commit 491404fa6e6f95eb14683c3c06d10ddc5f8e883f (HEAD -> master) Author: john <john@163.com> Date: Wed Sep 26 20:01:14 2018 +0800
third commit
commit e838c8678ef789df84c2666495663060c90975d7
Author: john <john@163.com> Date: Wed Sep 26 19:47:22 2018 +0800
second commit
commit 7020a97c0e792f340e00e1bb8edcbafcc4dfb60f
Author: john <john@163.com> 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引用實現的。