作者：lzaneli，腾讯 TEG 前端开发工程师
本文以一个具体例子结合动图介绍了Git的内部原理，包括Git是什么储存我们的代码和变更历史的、更改一个文件时，Git内部是怎么变化的、Git这样实现的有什么好处等等。
通过例子解释清楚上面这张动图，让大家了解Git的内部原理。如果你已经能够看懂这张图了，下面的内容可能对你来说会比较基础。
视频链接：
https://ww E 9w.bilibili.com/video/av77252063
P+ J k h 6 3 | r PPT 链接：
https://www.lzane.com/slide/git-under-the-hood
前言
近几年技术发展十分迅猛，让部分同学养成了一种学习知识停留在表面，只会调用一些指令的习惯。我们时常有一种“我会用这个技术、这个框架”的错觉，等到真正遇到问H m K - k W i 7 Q题，才发现事情没有那么简单。
而Git也是一个大部分人都知道如何去使用它，知道有哪些命令，却只有少部分人知; N T d , S e 8 f道具体原理的东西。了解一些底层的东西，可以更好的帮你理清思路，知道你真正在操作什么，不会迷失在Git大量的指令和参数$ M x A上面。
Git是怎么储存信息的
这J 2 z 4 y里会用一个简单的例子让大家直观感受一下git是怎么储存信息的。
首X , ` j先我S G -们先创建两个文件
$ git init
$ ei ! 8 0 pcho \'111\' > a.txt
$ echo \'222\' > b.txt
$ git add *.txt
Git会将整个数据库储存在.git/目录下，如果你此时去查看.~ j i J w bgit/objects目录，你会发现{ & 5 v E H Q K仓库里面多了两个object。
$ tree .git/objects
.git/objects
├── 58
│ └── c9bdf9d017f* y c p h V Gcd178dc8c073cbfcbb7ff240d6c
├── c2
│ └── 00906efd24ec5e783bee7f23b5d7c941b0c12c
├── info
└── pack
好奇的我们来看一下里面存的是什么东西
$ cat~ ~ N _ W M @ & .git/objects/58/c9bdf9d017fcd178dc8c073cbfcbb7ff240d6c
xKOR0a044K%
怎么是一串乱码？这是因为Git将信息压缩3 h s / 9 d 5成二进制文件。但是不用担心，因为Git也提供了一个能够帮助你探索它的api git catq % @-file [-t] [-p]， -t可以查看object/ F f _ . _ E @ P的类型，m H = Q J ( y W-p可以查看object储存的具体内容。
$ git cat-file -t= = ~ 58c9
blob
$ git cat-file -p 58c9
111
可以发现这个object是一个blob类型的节` g Z l ! _ v P点，他的内容是111，也就是说这个object储存着a.txt文件的内容。
这里我们遇到第一种Git object，blob类型，它只储存的是一个Y G % ~ d文件的内容，不包括文件名等其他信息。然后将这些信息经过SHA1哈希算法得到对应的哈希v ^ G v =值58c9bdf9d017fcd178dc8c073cbfcbb7ff240d6c，作为这个ob Z o Uject在Git仓库中的唯一身份证。
也就是说，我们此时的Git仓库是这样子的：
我们继续探索，我们创建一个commit。
$ git commit -am \'[+] init\'
$ tree .git/objects
.git/objects
├── 0c
│ └── 96bfc59d0f02317d002ebbf8318f46c7e47ab2
├── 4c
│ └── aq | @ O . . ~ G %aa1a9ae0b274fba9e3675f9ef071616e5b209
...
我们会发现当我们commit完成之后，Git仓库里面多出来两个object。同样b # 0 : : u Y使用cat-file命令，我们看看它们分别是什么类型以及具体的内容是什么。
$ git caY g m + d x 0 N ;t-file -t 4caaa1
tc g X X y ; f Uree
$ git cat-file -p 4caaa1
100644 blob 58c9bdf9d017: B 2 : b , Rfcd178dc8c0... a.txt
100644 blob c200906efd24ec5e783bee7... b.txt
这里我们遇到了第二种Git object类型——tree，它将当前的目录结构打了一个快照。从它储存的V ~ Z | * 9 c U内容来看可以发现它储存了一个目录结构（类似于文件夹），以及每一个文件（或者子文件夹）的权限、类型、对应的身份证（SHA1值）、以及文件名] n q K { L L v。: 8 M ( E 5 !
此时的Git仓库是这样的：
$ git cat-file -t 0c96bf
commit
$ git cat-file -p 0c96bf
tree 4caaa1a9ae0b274fba9e3675f9ef071616e5b209
author lzanF T = X A K Ve 李泽帆 15733B E ` R 102343 +0800
committer lzane 李泽帆 1573302343 +0800
[+] init
接着5 2 D L t我们发现了第三种Git object类型——commit，它储存的是一个提交的信息，包括对应目录结构的快照tree的哈希值，上一个提交的哈希值（这里由于是第一个提交，所以没有父节点。在一个merge提9 S g m R y K交中还会出现多个父节点），提交的作者以及提交的具体时间，最后是该提交的信息。
此时我们去看Git仓库是这样的：
到这里我们就知道Git是怎么储存一个提交的信息的了，那有同学就会问，我W = k们平常接触的分支信息储存在哪里呢？
$ cat .git/HEAD
ref: refs/heads/master
$ cat .git/refs/heads/master
0c96bfc59d0f02317d002ebbf8318f46c7e47aL F + ; - a t Db2
在Git仓库里面，HEAD、分支、普通的Tag可以简单的理解成是一个指针，指向对应commit的SHA1值。
其实还% 1 a r - 6 G有第四种Git object，类型是tag，在添加含附注的tag（git tag -a）的时候会新建，这里不详细介绍，有兴趣的朋友e l _ i按照上文中的方法可以深s n 5 O r _入探究。
至此我们知道了Git是什么储存一个文件的内容、目录结构、commit信息和分支的。其本质上是一个key-value的数据库加上默克尔. I E h树形成的有向无环图（DAG）。这里可 N c V U i w D R以蹭一下区块链的热度，区块链的数据结构也使用了默克尔树。
Git的三个分区
接下来我们来看一下Git的三个分区（工作目录、Index 索引区域、Git仓库），以及Git变更记录是怎么形7 f Z T , H成的。了解这z }三个分区和Git链p M o j }的内部原理之后可以对Git的众多指令有一个“可视化”的理解，不会再经常搞混。
接着上面的例子，目前的仓库状态如下：
这里有三个区域，他们所储存的信息分别是：
- 工作目录 （ working directorp 8 v l Z # d 3y ）：操作系统上的文件，所有代码开发编辑都在这上面完成。
- 索引（ index or staging area ）：可以理解为一个暂存区域，这里面的代码会在下一次commit被提交到Git仓库。
- Git仓库（ git repository ）：f G 7由Git object记录着每一次提交的快照，以及链式结构记录的提交变更历史。
我们来看一下更新一个文件的内容这个过程会发生S % ` = [ ?什么事。
运行echo \"333. A m ` .\" >8 5 $ 9 n a B h; a.txt将a.txt的内容从` ! y111p 8 j d B N ) 7修改成333，此时如上图可以看到3 6 ( }，此S 4 # 5 J 时索引区域和git仓库没有任何变化。
运行git add a.txt将a.] ! % t Mtxt加入到索引区域，此时如上图所示，git在仓库里面新建了一个blob object，储存了新的文件内容。并且更新了索引将a.txt指向了新建的L S u ( ; ;blob object。
运行git commit -m \'update\'提交这次修改。如上图所示
- Git首先根据当前的索引生产一个tree object，充当新提交的一个快照。
- 创建一个新的c` _ ( _ C 4 c yommit object，将这次commit的信息储存起来，并且parent指向上一个commit，组成一条链记录变更历史。
- 将master分支的指针移到新的commit结点。
至此我们知道了Gi8 T f T 0 r z ,t的三个分区分别是什么以@ L Q及他们的作用，以及历史链是怎么被建立起来的。基本上Git的大部分指令就是在操作这三个分区以及这条链。可以尝试的思考一下git的各种命令，试一下你能不能够R W / / g 5在上图将它们“可视化”出来，这个很重要，T D ] 6 # , X /建议尝试一下。
如果不能很好的将日常使用的指令“可视化”出来，推荐阅读 图解Git
一些有趣的问题
有兴趣的同学可以继续阅读，这部分不是文章的主要内容
问题1K T } * Y：为什么要把文件的权限和文件名储存在tree obj/ L v J r #ect里面而不是blob object呢？
想象一下修改一个文件的命名。
如果将文件名保E K l $ D !存在blob里面，那B [ # a 5 I n 0么Git只能多复制一份原始内容形成一个新t F z z的blob objecU 2 6 T # h S v qt。而Git的实现方法只需要创建一个新的tC # Xree object将对应的文件名更改成新的即可，原本的blob object可以复用，节约了空间。
问题2：每次commit，Gu : s e L - Nit储存的是全新的文件快照还是储存文件的变更部分？
由上面的例子我们可以看到，Git储存的是全新的文件快照，而不是文件的变更记录。也就是说，就算你只P ~ ^ % F ]是在文件中添加一行，Git也会新建一个全新的blob object。那这样子是不是很浪费空间呢?
这其实是Git在空间和时间上的a i V ] q L J一个取舍，思考一下你要checkout一个commit，或对比两个commit之间的差异。如果Git储存N 1 w H的是问卷的变更部分，那么为了拿到一个commit的内容，Git都只能从第一个commit开始，然h ] ^ B后一直计算变更，直到目标commit，这s V = |会花费很长时间。而相反，Git采用的储存全新文件: y ) H $ n * K快照的方法能使这个操作变得很快，直接从快照里面拿取内容就行了。
当然，在涉及网络传输或者Git仓库真的体积很大的时候，Git会有垃圾回收机制gc，不仅会清除无用的of Y } W t # ; Jbject，还会U C R V O w X {把已有的相似objectJ L ` E e 7 p W h打包压缩。
问题3：Gitt o A 0怎么保证历史记录不可篡改？
通过SHA1哈希算法和哈系树来保证。假设你偷V 9 u偷修改了历史变更记录上一个文件的内容，那么这个问卷的blob object的SHA1哈希值就变了，与之相关的tree object的SHA1也需要改变，commit的SHA1也要变，这个com! . jmit之后的所有commit SHA1值也要跟着改变。又由于Git是分布式系统，即所有人都有一份完整历史的Git仓库，所以所有人都能很轻松的发现存在问题。
希望大家读完有& l f 9 ( v B所收获，下一篇文章会写一些我日常工作中觉得比较实用的Git技巧、经常被问到的问题、以及发生一些事故时的处理方法。