Git 3.0 计划将默认哈希算法从 SHA-1 切换至 SHA-256，这一变革被开发者 Scott Chacon 称为“代价高昂且可避免的错误”。尽管该变更旨在应对理论上存在的哈希碰撞风险，但文章指出，这种迁移将给全球 Git 生态系统带来巨大的兼容性与信任机制挑战。
Git 的核心设计基于内容寻址数据库（Content Addressable Database），即通过计算文件内容的哈希值作为键存储数据。自 2005 年 Linus Torvalds 创建 Git 以来，SHA-1 一直是默认的哈希函数。这种机制确保了相同内容在全球范围内拥有相同的哈希值，并通过提交对前序提交的哈希编码实现了加密完整性传播。
从数学角度看，SHA-1 的 160 位输出意味着在单个项目中需要约 1.4 quadrillion billion（1,400,000,000,000,000 billion）个随机文件才可能发生意外碰撞。然而，随着 2017 年 SHAttered 和 2020 年 SHA-1 is a Shambles 等攻击论文的发表，SHA-1 被视为“半破解”状态。虽然目前尚无实际可行的利用方式，但理论上存在通过 GPU 集群进行碰撞攻击的可能性。
为应对这一理论风险，Git 3.0 拟将默认算法改为更强大的 SHA-256。但批评者认为，“破解”在此语境下仅指找到碰撞并非不可能，而非哈希函数完全失效。即便假设攻击成本极低，现实中的安全威胁主要源于社会工程攻击、依赖包投毒或维护者账户被盗，而非复杂的哈希碰撞攻击。正如 Linus Torvalds 在 2005 年所言：“真正的安全在于分销”，信任应建立在来源验证上，而非单纯依赖哈希算法。
若强制推行 SHA-256 默认值，将引发一系列严重的生态碎片化问题：
- 仓库隔离与推送失败：新初始化的仓库将使用 SHA-256，而旧仓库仍使用 SHA-1。由于两种格式无法混合，用户需明确知晓本地 Git 版本及远程服务器配置，否则极易遭遇
fatal: the receiving end does not support this repository's hash algorithm错误。 - 子模块兼容性危机：库项目若需同时支持新旧格式，必须维护两个版本的子模块，极大增加了复杂性。
- 链接与签名失效：现有项目若转换为 SHA-256，所有历史对象需重新计算哈希，导致现有 GPG/SSH 签名失效。此外，所有包含 40 字符 SHA-1 哈希的外部链接（如 Slack 消息、邮件、文档引用）将全部断裂。
- 工具链崩溃：大量第三方 Git 实现库（非核心 C 语言库）缺乏对双格式的支持。依赖这些库的脚本和工具将在新仓库中无法正常工作。
据 Google 工程师 Emily Shaffer 透露，Google 内部正准备通过系统级覆盖策略，尽可能延长新项目使用 SHA-1 的时间，以规避此次迁移带来的混乱。
Scott Chacon 提出了一种替代方案：保留 SHA-1 作为内容检索键，但在签名时独立计算树内容的 SHA-256（或 BLAKE3）哈希，并将该哈希注入到签名字段中。这样，签名既覆盖了基于 SHA-1 的内容和历史，也包含了独立的 SHA-256 内容验证哈希。此方法可在不分裂整个 Git 生态的前提下，解决理论上的碰撞担忧，同时保持向后兼容性。
