前言
我们知道Git是一款优秀的版本控制工具，在分支管理方面相比SVN有很大优势。SVN创建分支的原理实际上是对于整个文件的拷贝，那么Git如何实现的呢？为什么效率就比SVN高？通过学习Git的内部原理，大家会有很清楚的认识。
Git仓库结构
当我们使用git init命令使文件变成可以由git管理的目录后，会在当前文件目录下生成.git目录的文件，说明git版本控制工作主要在这个目录里。先来看下.git文件的目录结构。
我们在一个目录下建立2020_05_24_git目录，执行git init初始化仓库
这是一个处于初始状态的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指的最终提交。
生成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的关系组织为下面这幅示意图:
通过上图我们可以得出结论：
- commit是对象关系图的入口；
- tree对象用于描述目录结构，每个目录节点都会用一个tree对象表示。目录间、目录文件间的层次关系会在tree对象的内容中体现；
- 每个commit都会有一个root tree对象，代表项目根路径;
- blob对象为tree的叶子节点，它的内容即为文件的内容
关于这三者的关系算是有点概念了，那么如果我修改了test.txt文件的内容并提交，会发生什么？
修改版本库已存在的文件时，objects目录结构的变化
我们修改src/test.txt文件的内容，并提交到本地仓库后，构建出所有object的关系组织示意图：
通过上图我们可以看到：
- 生成了新的blob对象，其父层的object对象也相应改变；
- 新生成的commit对象会将第一个commit对象作为parent；
如果在根目录下添加文件并提交，会发生什么？
在已有目录之外新增文件，objects目录结构的变化
在根目录下新建tes2.txt文件，并提交到本地仓库后，构建出所有的object的关系组织示意图：
通过上图我们可以看到：
- 生成了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对象。
默克尔树是一类基于哈希值的二叉树或多叉树，其叶子节点上的值通常为数据块的哈希值，而非叶子节点上的值，是将该节点的所有孩子节点的组合结果的哈希值。默克尔树的特点是，底层数据的任何变动，都会传递到其父亲节点，一直到树根。
branch和tag之所以轻量，因为它们都是“指针”
使用subversion时，创建branch或打tag使用的是svn copy命令。svn copy执行的就是真实的文件拷贝，相当于将trunk下的目录和文件copy一份放到branch或tag下面，建立一个trunk的副本，这样的操作绝对是“超重量级”的。如果svn仓库中的文件数量庞大且size很大，那么svn copy执行起来不仅速度慢，而且还会在svn server上占用较大的磁盘存储空间，因此使用svn时，打tag和创建branch是要“谨慎”的。
