git的commit值是怎么计算出来的

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

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

$ git show
commit 19d02d2cc358e59b3d04f82677dbf3808ae4fc40 (HEAD -> master, origin/master, origin/HEAD)
Author: Evan Liu <hmisty@gmail.com>
Date:   Tue Jan 16 13:46:12 2018 +0800

    go fmt

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

$ git cat-file commit HEAD
tree df7d111a2509509177674d965b99df8399b8168e
parent b0f8a1eb2a567ec7d163ce9d91d82f676070be2b
author Evan Liu <hmisty@gmail.com> 1516081572 +0800
committer Evan Liu <hmisty@gmail.com> 1516081572 +0800

go fmt

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

$ printf "commit %s\0" $(git cat-file commit HEAD | wc -c)
commit 209

连起来就是：

$ printf "commit %s\0" $(git cat-file commit HEAD | wc -c); git cat-file commit HEAD
commit 209tree df7d111a2509509177674d965b99df8399b8168e
parent b0f8a1eb2a567ec7d163ce9d91d82f676070be2b
author Evan Liu <hmisty@gmail.com> 1516081572 +0800
committer Evan Liu <hmisty@gmail.com> 1516081572 +0800

go fmt

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

$ (printf "commit %s\0" $(git cat-file commit HEAD | wc -c); git cat-file commit HEAD) | shasum
19d02d2cc358e59b3d04f82677dbf3808ae4fc40  -

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

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

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

commit 19d02d2cc358e59b3d04f82677dbf3808ae4fc40 (HEAD -> master, origin/master, origin/HEAD)
Author: Evan Liu <hmisty@gmail.com>
Date:   Tue Jan 16 13:46:12 2018 +0800

    go fmt

commit b0f8a1eb2a567ec7d163ce9d91d82f676070be2b
Author: Evan Liu <hmisty@gmail.com>
Date:   Tue Jan 16 13:38:33 2018 +0800

    panicIfError

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

tree df7d111a2509509177674d965b99df8399b8168e
parent b0f8a1eb2a567ec7d163ce9d91d82f676070be2b
author Evan Liu <hmisty@gmail.com> 1516081572 +0800
committer Evan Liu <hmisty@gmail.com> 1516081572 +0800

go fmt

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

$ git cat-file -p df7d111a2509509177674d965b99df8399b8168e
100644 blob 5520cde3cf15000bbe6b67442aab61cfbe0cf2d8    .gitignore
100644 blob 3e8d19f93f71e7a062e6009d6719f16cab3e2f30    DEV_GUIDE.md
100644 blob c3a0aa959a84f2df7c109caa1c75627bd5a9bb63    LICENSE
100644 blob 9efb0fcbae6204c32395dcbf63089ad04649fc66    README.md
100644 blob 60a1bf18843435f1b3fd2f016d1785469ffcd4d6    RELEASE_NOTES
100644 blob a33deeeb9b407f59fd447a708cf5dcc3edb78b27    SPEC.md
040000 tree 7b1d8214bd1384a5e48e3d17e8a12922ef52b505    bson_rpc
040000 tree 06602aa29e5a662aaa34b6a7b1b1530185652efa    examples
100644 blob f7a7f93c52486f321619222c0611864ce1631803    requirements.txt
100644 blob 0e579f6e256123a752ebaa332d488c546d4a07c5    setup.py

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

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

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

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

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

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

...
|
V
commit hash3
. tree hash ---------> tree of hashes of objects (Merkle Tree)
. parent hash
|
V
commit hash2
. tree hash ---------> tree of hashes of objects (Merkle Tree)
. parent hash
|
V
commit hash1
. tree hash ----------> tree of hashes of objects (Merkle Tree)
. parent hash
|
V
创世哈希（0000000000000000000000000000000000000000）

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

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

QY 20180117