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