• • 更新**：* 我已经写了更详细的答案。*

一个...

• 树（所有文件和目录）ID由...
• 所有文件的内容，而不是diff，称为blob。
• 目录树（文件和目录的名称以及它们的组织方式）。
• 所有文件和目录的权限。
• 父提交ID。
• 日志消息。
• 提交者姓名、电子邮件和日期。
• 作者姓名和电子邮件日期。

如果您更改了提交的任何内容，提交ID也会随之更改。
包含父提交ID是非常重要的。这意味着两个内容完全相同的提交，但是构建在不同的父提交上，仍然会有不同的ID。为什么要这样做？这意味着如果两个提交的ID相同，你就知道它们的整个历史记录是相同的。这使得比较和更新Git仓库 * 非常 * 高效。"我在提交ABC123处有分支foo，你也是吗太好了我们同步了"
在比较Git和其他版本控制系统时，请记住，在许多流行的"可靠"系统中，如Subversion或CVS，任何拥有文件权限的人都可以进入并不被察觉地更改中央仓库中的历史记录。使用Git，这种篡改会立即被检测到，因为它会更改所有下游提交ID，或者如果它们brute force matched the IDs，内容将完全是无稽之谈。
sha1碰撞的可能性已经被考虑过了。长话短说，在冲突中现有的对象获胜。
The probability of a SHA1 collision happening accidentally is so vanishingly small，我希望你的小行星，宇宙射线，和狼攻击保险都付清了。
如果地球上的65亿人都在编程，那么每一秒钟，每个人都在产生相当于整个Linux内核历史的代码（360万个Git对象）并将其推到一个巨大的Git存储库中，大约需要2年的时间，直到该储存库包含足够的对象，以具有50%的单个SHA-1对象碰撞的概率。更大的可能性是，您的编程团队的每个成员都将在同一个晚上在不相关的事件中被狼攻击并杀死。
说真的，还有更好的事情要担心，比如100分之一的驱动器故障几率。你的备份怎么样了？

Git仓库中存储了几种不同类型的对象，blob对象存储文件的原始数据，tree对象存储文件模式（例如是否为只读）、对象类型和名称。
您可以在Git Community Book中找到更多详情。
哈希值如此之多，以至于发生意外冲突的机会微乎其微。
但是，真正相同的内容将具有相同的哈希：因此，如果两个人独立地对文件做出相同的改变，则两个（相同的）BLOB对象将具有相同的散列;提交对象将是不同的，并且将具有不同的散列，但是两个提交将引用相同的blob散列。2如果这两个提交稍后被合并，则将仅保留blob的一个副本（这是好的，因为内容是相同的）。