一，将对象增加到暂存区
上篇文章中，已经构建的库中应该存在下图这样的文件了。
1，将第一个对象加入到暂存区先：
此时的哈希值是第一个树对象。
这样一来，就在暂存区中有了第一个树对象）：
上图中第一个便是第一个树对象，现在从库里复制到暂存区来了，后两个则是第二个树对象包含的文件（git对象）。
但实际上，到这里第三个树对象还没有完全生成，还需要把它搞进库里。
再看看版本库：
三个文件对象，三个树对象了。
查看这第三个树对象的内容：
也就是说，第三棵树对象的快照如下图：
但是这样在实际中没啥用，因为第三个树对象没变更啥，，，
问题
现在有三个树对象（执行了三次 write-tree），分别代表了我们想要跟踪的不同项目快照。然而问题依旧：若想重用这些快照，你必须记住所有三个SHA-1 哈希值。 并且，你也完全不知道是谁保存了这些快照，在什么时刻保存的，以及为什么保存这些快照。 而以上这些，正是提交对象（commit object）能为你保存的基本信息
二，提交对象
2-1，现在来为第一个树对象创建提交对象：
2-2，查看生成的对象的类型为提交对象
2-3，查看此提交对象的内容：
在这里就会看到是谁修改的，修改了那些内容。
也就是我们之前的做法，都漏了一步提交对象，应该每次生成一个树对象，就应该创建一个提交对象。用以存储变更的具体信息。
2-4，现在来创建第二个树对象的提交对象，因为已经有第一个提交对象了，所以创建第二个提交对象时，有一点小小的区别，需要把前一个提交对象连接起来。
查看第二次创建的提交对象的信息：
于是，这样做下去的话，示意图会变成
也就是说，真正代表一个项目版本的，应该是提交对象。我们需要直接访问提交对象。虽然树才是一次版本的封装，但是提交对象是这个树对象和版本变更信息的封装。
而且，提交对象是链式的！
也就是说一个合格的提交对象至少包哈三个部分内容
- 当前版本（树对象）
- 上一个版本的提交对象的哈希值（索引）
- 本次变更的信息
此时，你的objects目录下存着所有的版本信息，如果需要回溯版本，只要找到对应提交对象的哈希值，就可以直接跳过去。
也就是树对象，git对像，你压根就不用管，你只要知道提交对象的哈希值就可以了！！！因为外部会有一个指针来指向你需要的版本对应的提交对象。