众所周知，代码版本管理工具git会为每一个版本提交创建一个commit值。这个值是一个SHA-1哈希，那么这个值是怎么计算出来的呢？往下看。

我们来看一个仓库的最后一次commit hash值：

字符串19d02d2cc358e59b3d04f82677dbf3808ae4fc40就是最后一次提交的commit hash。这个hash大概是由下面的信息计算出来的：

但这还不够，前面要加一个commit NNN，就像这样：

连起来就是：

对上面的输出求SHA-1就可以得到正确的结果了：

在你的电脑上求SHA-1的命令可能叫做shasum或者sha1sum。

这正是我们最初git show查看的commit hash。

让我们用git log命令看一下之前版本的commit hash：

我们回头来看一下作为commit hash计算输入的输入都包含了哪些信息：

第一行，tree哈希，根据这个哈希可以展开本次commit的整个目录树及每个对象的hash值。如果感兴趣，可以用 git cat-file -p 哈希值 来查看到底都是些什么对象：

这里面所有的哈希都可以继续用git cat-file -p继续展开，一直到叶子节点（文件）。

第二行，parent哈希，正是上一个commit的hash值。

第三行，author，时间戳1516081572是2018/1/16 13:46:12，本次提交的时间。

第四行，committer，时间戳仍然是本次提交的时间。

剩余部分是提交时所写的notes。

所以，我们大概可以在脑海中构想出git提交的一个链条结构：

每一次新版本的提交，git commit都会让这个链条的哈希高度增加一层，用git log可以看到这个大楼。

可以看到，git的每次commit hash都是包含上一次commit hash以及本次修正的文件结构的Merkle Tree的Merkle Root，有没有觉得和block chain区块链的设计思想有异曲同工之处呢？只不过，git的哈希链是一个DAG（Directed Acyclic Graph，有向无环图），而区块链的哈希链是一个由随机抢答产生的哈希数连接起来的链。

QY 20180117