Git中为何存在长哈希值？——关于短哈希作为提交ID的疑问

Git 里的长哈希（40位十六进制的 SHA-1 字符串）是整个版本控制系统的核心基础，短哈希只是为了用户便捷而生的简化形式，长哈希存在的原因主要有这几点：

• 绝对的唯一性保障
  短哈希只是长哈希的前缀，在小型仓库里，几位前缀就足够区分所有提交，但随着仓库提交量增长、分支增多，短前缀出现重复的概率会越来越高。长哈希的长度足够确保，在几乎所有场景下（甚至是全球最大的代码仓库，比如 Linux 内核），每个提交的哈希都是独一无二的，不会出现两个不同提交共享同一长哈希的情况。

• 分布式协作的核心需求
  Git 是分布式系统，每个开发者的本地仓库都有完整的提交历史。如果只用短哈希，不同开发者的本地仓库可能出现提交短前缀重复的情况，一旦协作合并就会产生歧义。长哈希是全局一致的——无论在哪台机器上，同一个提交的长哈希完全相同，这就保证了跨仓库协作时的精准定位，不会搞混提交。

• 提交完整性与安全性
  Git 的哈希是基于提交的所有内容生成的：包括父提交哈希、作者信息、提交时间、改动的文件内容等，任何一点修改都会导致哈希完全变化。长哈希的长度提供了足够的抗碰撞能力（尽管 SHA-1 存在理论碰撞风险，但 Git 后续也在支持 SHA-256），能有效防止提交被篡改后伪装成原提交，短哈希的长度不足以提供这种安全保障。

• 底层存储的依赖
  Git 的底层对象数据库（存储提交、树对象、Blob 对象等）是直接用长哈希作为唯一标识来存储和检索的。所有内部操作（比如查找提交、校验对象完整性）都是基于长哈希完成的，短哈希只是 Git 为用户提供的“快捷方式”，底层依然依赖长哈希来正常运转。

内容的提问来源于stack exchange，提问作者Altay Turan