从前面我们可以知道，git底层是以元数据的方式存储，我们来新建一个仓库，查看一下objects内容：

find .git/object/

可以看到 Git 对 objects 目录进行了初始化，并创建了 pack 和 info 子目录，但均为空。

下面新建并提交一个新文件，看一下元数据，在仓库根目录查看元数据文件的命令：

find .git/objects/ -type -f

我们可以看到，只提交了一个文件，但是元数据多了三个，这三个分别是什么呢？这三个分别是数据对象，提交对象和树对象。下面来详细说一下这三个对象。也就是git的底层原理。

Git数据对象

Git 本质上是一个内容寻址的文件系统，其核心部分是一个简单的键值对数据库（key-value data store），在不进行提交操作的情况下，你仍然可以向数据库中插入任意内容，它会返回一个用于取回该值的hash 键（key）。如果内容一样，那么返回的key也一样。我们来创建一个新仓库，创建一个新文件hello.txt，然后插入到键值数据库中，尝试插入多次，查看返回的key是否一样：

git hash-object -w hello.txt

可以看到多次插入返回的key是一样的。我们稍微改变一下内容，就会发现返回的键发生变化：

还可以基于键获取指定的内容：

git cat-file -p 3ea522c66db4133cf6135a2764e33905c841780f

键值只要保证唯一，输入前几位即可。

上面演示的就是git作为简单键值对数据库的基本操作。前面说过，git是基于元数据的存储方式，元数据存储在.git文件夹下面的objects文件夹中。那么我们来查询一下objects下面所有的文件，也就是git对象：

find .git/objects/ -type f

显示两个文件名就是我们刚才保存的文件两个版本的key。这和上面演示的提交不同，单纯的把数据插入到数据库只生成一个元数据。

这个时候再来看版本回退，从本质上来说，版本变化了2次，目前文件内容是第2次的修改，如果想回退到第一个版本，那么本质上只需要把第一个版本的元数据写回到当前文件中即可，先来看一下现在文件的内容：

显示的是第2个版本，也就是最新版本的内容，我们现在来恢复到第一个版本，第一个版本的key是  3ea522c66db4133cf6135a2764e33905c841780f，我们来吧第一个版本的内容写到文件中：

git cat-file -p 3ea522c66db4133cf6135a2764e33905c841780f > hello.txt

这样就实现了一个版本的回退。文件内容也恢复到了第一个版本的内容。我们在进行git的版本回退时，git底层存储实际上就是这么做的。我们存储的元数据并不是普通的文件，而是一个blob对象，来看下数据类型：

git cat-file -t 3ea522c66db4133cf6135a2764e33905c841780f

blob对象就是我们git的实际存储的文件的数据类型。然而，记住文件的每一个版本所对应的 key并不现实；另一个问题是，在这个（简单的版本控制）系统中，文件名并没有被保存——我们仅保存了文件的内容。 上述类型的对象我们称之为数据对象（blob object）。 利用 cat-file -t 命令，可以让 Git 告诉我们其内部存储的任何对象类型，只要给定该对象的key值。

看完了上面的底层操作，再来看一下git命令操作，新建一个文件test.txt，然后添加到暂存区：

再来看一下元数据：

添加到暂存的命令虽然没有返回key，但是从元数据数量上来看，明显多了一条数据，其实本质上添加到暂存区也要执行git hash-object -w命令。而且添加到暂存区也只是新增了存储对象，并没有提交对象和树对象，因此只多了一条。我们上面用数据库操作把hello.txt文件添加到了键值数据库中，现在再来用git add添加，看看数据会不会增多：

可以看到数据依然是3条，没有变化，数据的key也没有改变，这是因为我们上面已经添加了，同样的数据添加几次生成的key都是一样的。

Git树对象

在上面的数据对象中，提到了记住每个版本对应的key肯定是不现实的，文件名也没有被保存，接下来要探讨的对象类型是树对象（tree object），它能解决文件名保存的问题，也允许我们将多个文件组织到一起。 Git 以一种类似于 UNIX 文件系统的方式存储内容，但作了些许简化。 所有内容均以树对象和数据对象的形式存储，其中树对象对应了 UNIX 中的目录项，数据对象则大致上对应了 inodes 或文件内容。 一个树对象包含了一条或多条树对象记录（tree entry），每条记录含有一个指向数据对象或者子树对象的 key指针，以及相应的模式、类型、文件名信息。

树对像解决了文件名的问题，它的目的是将多个文件名组织在一起，其内包含多个文件名称与其对应的Key和其它树对像的引用，可以理解成操作系统当中的文件夹，一个文件夹包含多个文件和多个其它文件夹。

上图中，顶层的tree对象下面有两个blob对象，代表两个文件，第三个是个tree对象，代表子文件夹，下面还是一个blob对象，表示子文件夹下面的文件。

简单介绍完树对象，下面我们新建一个仓库，提交一些内容：

上面我们新建了一个仓库test，在仓库下新建了一个test.txt文件和一个hello文件夹，在hello文件夹下面新建了一个hello.txt文件，然后回到仓库根目录对仓库所有内容进行了整体的一个提交。当前对应的最新树对象是这样的：

git cat-file -p master^{tree}

master^{tree} 语法表示 master 分支上最新的提交所指向的树对象。 请注意，hello 子目录（所对应的那条树对象记录）并不是一个数据对象，而是一个指针，其指向的是另一个树对象：

git cat-file -p 62be0186dd46837d7efe02bdf2e3c3731a7ed2fe

可以看到树对象下面存储了文件的key，文件的名称和下级的树对象，是个经典的树形结构。大家可以想象我们平时开发的项目提交到git仓库，就是文件系统转化为树对象和数据对象的过程。

可以想象到，文件夹下面的文件更新后，文件夹树对象以上的所有树对象都会发生变化，但是下层的不会变，虽然会生成很多key，但是指向关系非常明确，有兴趣可以自行验证。

Git提交对象

现在假如有三个树对象，分别代表了我们想要跟踪的不同项目快照。然而问题依旧：若想重用这些快照，你必须记住所有三个key。 并且，你也完全不知道是谁保存了这些快照，在什么时刻保存的，以及为什么保存这些快照。 而以上这些，正是提交对象（commit object）能为你保存的基本信息。什么是提交对象呢？来看一下操作日志：

第一行commit后面跟着一个hash值，就是提交对象的key，每次提交都会对应一个提交对象。提交对象下面是什么呢？来看一下：

可以看到提交对象对应的就是一个树对象，有几次提交就会对应几个树对象，树对象很抽象并且不好记住，但是提交对象通过提交记录很容易就能找到。我们再来看一下这个树对象下面是什么：

可以看到这个树对象就是我们上面根据分支查询到的树对象：

这就是提交对象和树对象对应的一个关系。提交对象的格式很简单：它先指定一个顶层树对象，代表当前项目快照；然后是作者/提交者信息（依据你的 user.name 和 user.email 配置来设定，外加一个时间戳）；留空一行，最后是提交注释。

我们来修改一下test.txt文件并提交，再看一下提交对象：

这时候产生了第二个提交对象。

可以看到第二次的提交对象中还包含了一个父提交对象，指向的是第一次的提交对象。通过这种链接可以明确提交对象的顺序。

每次我们运行 git add 和 git commit 命令时， Git 所做的实质工作——将被改写的文件保存为数据对象，更新暂存区，记录树对象，最后创建一个指明了顶层树对象和父提交的提交对象。 这三种主要的 Git 对象——数据对象、树对象、提交对象——最初均以单独文件的形式保存在 .git/objects 目录下。 简单看一个提交三次后，各种对象的关系图：

大家可以想象我们通过这种方式管理元数据，一旦进行分支切换，版本回退等等操作，可以快速找到对应的key指向的内容，然后再把内容恢复到现在的目录中，是何等的快速！

上面三种对象是git仓库真正的核心部分，其他的像分支，标签等等都是对其中一个提交对象的引用，可以在.git/refs 文件下面看到。我们来看下master分支的引用：

这个key就是我们仓库的提交对象：

所谓的分支标签就是这么一回事。

我们的交流基地，“JAVA互联网技术交流：789650498”欢迎小伙伴们一起来交流：