前言

我们知道Git是一款优秀的版本控制工具，在分支管理方面相比SVN有很大优势。SVN创建分支的原理实际上是对于整个文件的拷贝，那么Git如何实现的呢？为什么效率就比SVN高？通过学习Git的内部原理，大家会有很清楚的认识。

Git仓库结构

当我们使用git init命令使文件变成可以由git管理的目录后，会在当前文件目录下生成.git目录的文件，说明git版本控制工作主要在这个目录里。先来看下.git文件的目录结构。

我们在一个目录下建立2020_05_24_git目录，执行git init初始化仓库

image.png

这是一个处于初始状态的git仓库，查看仓库目录

$ tree
.
|-- HEAD    // 当前引用
|-- config  // 这个是Git仓库的配置文件
|-- description // 仓库的描述信息，主要给gitweb等git托管系统使用
|-- hooks   // 存放一些shell脚本
|   |-- applypatch-msg.sample
|   |-- commit-msg.sample
|   |-- fsmonitor-watchman.sample
|   |-- post-update.sample
|   |-- pre-applypatch.sample
|   |-- pre-commit.sample
|   |-- pre-merge-commit.sample
|   |-- pre-push.sample
|   |-- pre-rebase.sample
|   |-- pre-receive.sample
|   |-- prepare-commit-msg.sample
|   |-- push-to-checkout.sample
|   `-- update.sample
|-- info
|   `-- exclude
|-- objects // 存放所有的git对象
|   |-- info
|   `-- pack
`-- refs    // 分支或tag信息
    |-- heads
    `-- tags

8 directories, 17 files

其中，最最重要的就是objects目录，其它的在这里就不展开了。

详解objects目录

概念(blob、tree、commit)

objects目录就是一个'筐'，git的核心对象都往里面'装'

objects目录主要存放三种类型的对象，blob、tree、commit，这三种对象是干嘛的，之间的关系放在最后再给大家讲。大概就是blob指定了一个文件、tree描述目录结构、commit指的最终提交。

image.png

生成blob文件(git add)

我们添加一个src/test.txt文件进入暂存区，即执行git add，查看目录结构如下

...
|-- objects
|   |-- 3b
|   |   `-- 18e512dba79e4c8300dd08aeb37f8e728b8dad
|   |-- info
|   `-- pack
...

我们有一个object已经被装入到“筐”中了。我们看到objects目录下是一些以哈希值命名的文件和目录，其中目录由两个字符组成，是每个object hash值的前两个字符。hash值后续的字符串用于命名对应的object文件。在这里我们的object的hash值(实质是sha-1算法)为3b18e512dba79e4c8300dd08aeb37f8e728b8dad，于是这个对象就被放入名为3b的目录下，对应的object文件为18e512dba79e4c8300dd08aeb37f8e728b8dad。

使用git cat-file -t查看object类型，git cat-file -p查看object的内容

$ git cat-file -t 3b18e512dba79e4c8300dd08aeb37f8e728b8dad
blob

$ git cat-file -p 3b18e512dba79e4c8300dd08aeb37f8e728b8dad
hello world

可以发现，这个object的类型是blob，内容就是前面test.txt文件的内容

生成tree、commit文件(git commit)

提交暂存区的变更，执行git commit命令

$ git commit -m "first commit"
[master (root-commit) e62c49a] first commit
 1 file changed, 1 insertion(+)
 create mode 100644 test.txt

查看.git目录结构如下

...
|-- objects
|   |-- 3b
|   |   `-- 18e512dba79e4c8300dd08aeb37f8e728b8dad  //blob
|   |-- 5a
|   |   `-- cc09a9c845b99fcd7849947502795b784deba8  //tree
|   |-- c3
|   |   `-- b8bb102afeca86037d5b5dd89ceeb0090eae9d  //tree
|   |-- c8
|   |   `-- 8f34a7728da3d6d5da7e690ba7e8c56b0d41a5  //commit
|   |-- info
|   `-- pack
...

可以发现，相比之前新增了3个目录文件，5a/cc09a9c845b99fcd7849947502795b784deba8
c3/b8bb102afeca86037d5b5dd89ceeb0090eae9d
c8/8f34a7728da3d6d5da7e690ba7e8c56b0d41a5

使用git cat-file -t查看object类型，git cat-file -p查看object的内容

$ git cat-file -t 5acc09a9c845b99fcd7849947502795b784deba8
tree
$ git cat-file -p 5acc09a9c845b99fcd7849947502795b784deba8
040000 tree c3b8bb102afeca86037d5b5dd89ceeb0090eae9d    src

$ git cat-file -t c3b8bb102afeca86037d5b5dd89ceeb0090eae9d
tree
$ git cat-file -p c3b8bb102afeca86037d5b5dd89ceeb0090eae9d
100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad    test.txt

$ git cat-file -t c88f34a7728da3d6d5da7e690ba7e8c56b0d41a5
commit
$ git cat-file -p c88f34a7728da3d6d5da7e690ba7e8c56b0d41a5
tree 5acc09a9c845b99fcd7849947502795b784deba8
author xxx <xxx> 1621842818 +0800
committer xxx <xxx> 1621842818 +0800

first commit

可以发现4个文件存在某种关系

blob、tree、commit文件的关系

要理清objects目录中各object间的关系，就必须要把握住一个关键概念：“每个commit都是git仓库的一个快照”

提交新文件时，objects目录结构的变化

以一个commit为入口，我们能将当时objects下面的所有object联系在一起。因此，上面4个object中的那个commit对象就是我们分析各object关系的入口。我们根据上述4个object的内容将这4个object的关系组织为下面这幅示意图:

image.png

通过上图我们可以得出结论：

• commit是对象关系图的入口；
• tree对象用于描述目录结构，每个目录节点都会用一个tree对象表示。目录间、目录文件间的层次关系会在tree对象的内容中体现；
• 每个commit都会有一个root tree对象，代表项目根路径;
• blob对象为tree的叶子节点，它的内容即为文件的内容

关于这三者的关系算是有点概念了，那么如果我修改了test.txt文件的内容并提交，会发生什么？

修改版本库已存在的文件时，objects目录结构的变化

我们修改src/test.txt文件的内容，并提交到本地仓库后，构建出所有object的关系组织示意图：

image.png

通过上图我们可以看到：

• 生成了新的blob对象，其父层的object对象也相应改变；
• 新生成的commit对象会将第一个commit对象作为parent；

如果在根目录下添加文件并提交，会发生什么？

在已有目录之外新增文件，objects目录结构的变化

在根目录下新建tes2.txt文件，并提交到本地仓库后，构建出所有的object的关系组织示意图：

image.png

通过上图我们可以看到：

• 生成了test2.txt文件对应的blob对象，其父层的root tree对象也相应改变；
• 原来根目录下的src目录对应的tree和blob对象不变；
• 新生成的commit对象会将第二个commit对象作为parent，这样多个commit对象之间构成一个单向链表；

默克尔树(Merkle Tree)

从上面的三次变更，我们看到无论哪种对象object，一旦放入到objects这个“筐”就是不可变的(immutable)。即便是第二次commit对test.txt进行了修改，git也只是根据test.txt的最新内容创建一个新的blob对象，而不是修改或替换掉第一版test.txt对应的blob对象。

对应目录的tree object亦是如此。如果某目录下的二级目录发生变化或目录下的文件内容发生改变，git会新生成一个对应该目录的tree对象，而不是去修改原先已存在的tree对象。

默克尔树是一类基于哈希值的二叉树或多叉树，其叶子节点上的值通常为数据块的哈希值，而非叶子节点上的值，是将该节点的所有孩子节点的组合结果的哈希值。默克尔树的特点是，底层数据的任何变动，都会传递到其父亲节点，一直到树根。

image.png

branch和tag之所以轻量，因为它们都是“指针”

使用subversion时，创建branch或打tag使用的是svn copy命令。svn copy执行的就是真实的文件拷贝，相当于将trunk下的目录和文件copy一份放到branch或tag下面，建立一个trunk的副本，这样的操作绝对是“超重量级”的。如果svn仓库中的文件数量庞大且size很大，那么svn copy执行起来不仅速度慢，而且还会在svn server上占用较大的磁盘存储空间，因此使用svn时，打tag和创建branch是要“谨慎”的。