git commit hash 是否等于存储库状态？

Question

每个 git commit 都有一个哈希值，它“标记”其内容。它是否也签署了提交的来源，或者只是用于哈希计算的提交数据本身？

换句话说：是否不可能（除了散列冲突）伪造第二个存储库，其头部提交具有完全相同的散列和相同的内容，但树的其余部分不同？

Answer 1

第二个问题的答案是肯定的（这是不可能的，等等）。

第一个问题的形式并不像我想象的那么好，因为提交哈希实际上只是基于提交数据。导致第二个问题的答案的关键是“提交数据”包括这些关键项目，您可以在实际提交中看到：

$ git cat-file -p HEAD
tree 22abd5c3fed5e2f49fb71e10b39d8c4929e51fc7
parent 4ebdeb68ba87282f87c39d790ba17fe1e021cc97
parent 9eabf5b536662000f79978c4d1b6e4eff5c8d785
[snip]

该tree行给出了树的散列（仅取决于树的内容），而parent行（在本例中为两行，如HEAD合并提交）给出了父提交的散列。鉴于当前提交的散列取决于其树和父项的散列，如果您要构建具有不同历史记录或不同树的不同存储库，那么这些将具有不同的散列，以便提交也有不同的哈希值。

（这里通常使用的技术术语是Merkle Tree。）