Git存储结构
Git有四大组件，分别是：
- Tag
- Commit
- Tree
- Blob
当git初始化后，目录下就生成了.git文件夹，存放着与git相关的所有内容，我们看下目录下具体的内容：
所有的组件都存放在objects文件夹中：
Blob组件
当我们执行git add README.md后，文件夹内容如下：
我们可以看到，目录中多了83目录，即blog组件，83目录中有文件名是一串UUID的文件，当我们执行git add将文件变为staged状态后，就会在objects目录创建一个组件，组件都是以hash的二进制方式进行存储，组件的名称为文件夹名称+文件名称，所有上面的blob组件的名字即为83920ba13f0cd4e0046337313c1f0a1cfc676ad4，这个名字是唯一的。
当修改README.md后再次执行git add，发现，objects目录中又多了一个blob组件：
注意：如果两个文件的内容一样的话，执行git add的时候，只会生成一个blob组件，不会是两个。blob组件是在代码提交到Stage区域的时候生成的，而且是以内容来生成一个字节码文件。
可以通过git hash-object来查询文件的hash码：
Commit组件
刚刚我们已经执行了两次git add，下面我们将变动提交，执行git commit：
git commit -m "init"
可以看到，objects中多了两个文件夹，b6和da，这两个是什么呢？我们先用git log查看下提交日志：
可以看到，commit的id为da7b2dd822e576db1cfb0e546a9de57fc8cfbe8b，所以da文件夹为commit组件，那么b6是什么呢？
Tree组件
b6是tree组件，每次commit时，首先会创建commit组件，然后将涉及的文件信息创建tree组件，我们可以用git cat-file -p命令查看commit组件：
可以看到，通过git cat-file -p命令查看commit组件，可以看到tree组件，我们用git cat-file -p来查看tree组件：
可以看到，tree组件中记录了文件的基本信息。
底层运行流程
我们总结下git底层的运行流程：
- 当我们添加或者修改了文件并且add到stage区之后，会根据文件内容创建不同的blob
- 当进行提交之后马上创建一个tree组件把需要的blob组件添加进去，之后再封装到一个commit组件中完成本次提交。
- 在将来进行reset的时候可以直接使用git reset --hard xxxxx可以恢复到某个特定的版本
- 在reset之后，git会根据这个commit组件的id快速的找到tree组件，然后根据tree找到blob组件，之后对仓库进行还原
我们看到，git的整个过程都是以hash和二进制进行操作，所以git执行效率非常之高。
