Git 的下一个大版本正被描述为对多项长期沿用的设计选择进行协同调整,而不是一次普通的版本升级。LWN 在 2026 年 9 月 18 日的报道中表示,项目预计在 Git 2.56 发布后考虑推出 Git 3.0,并将涉及兼容性的变更纳入这个大版本。该报道的更新称,已经确定的发布顺序是:2026 年 12 月发布 Git 2.98,2027 年 4 月将 Git 2.99 作为长期支持版本发布,并在同一时间发布 Git 3.0。这一发布顺序由 LWN 报道;所提供的 Git 文档并未独立证实这一点。

Git 官方标志
Git 是版本控制系统,也是此次拟议中的 3.0 过渡的核心。git-scm.com

文章探讨了 Git 仓库对象、引用存储和构建要求的重大变化,因此官方项目标志能够直接标识这一系统。 来源及署名:git-scm.com。

最明确的变化,是提议将 Git 仓库使用的哈希算法从 SHA-1 切换为 SHA-256。Git 使用哈希来识别文件、目录树和提交,并验证历史链。LWN 解释说,SHA-1 被认为安全性较弱,而一次成功的攻击原则上可能使仓库历史难以被信任。Git 已经针对已知的 SHA-1 攻击设置了防御措施;LWN 还报道,自 2023 年的 Git 2.42 起,Git 就已经提供非实验性的 SHA-256 支持。这些说法说明的是安全方面的理由和实现历程;它们并不表明现有的 SHA-1 仓库目前正在遭到攻击。

因此,实际的迁移问题并不只是 SHA-256 是否更强。它还包括,围绕一个项目的仓库、托管服务和工具能否在过渡期间协同工作。LWN 报道,GitLab 和 Forgejo 已经支持 SHA-256,而所提供的材料并未明确说明 GitHub 是否已经支持。报道还称,GitHub 员工、迁移工作的参与者 brian m. carlson 表示,有关这一主题的消息即将到来,并暗示将下一个版本定为 Git 3.0 或许是合适的。这是参与者所作的归因性表态,并不是 GitHub 的产品公告,也不能证明兼容性已经具备。

另一个正在讨论的主要存储变更是 reftable。目前,Git 将分支和标签等引用作为文件存储在 `.git/refs/` 下,并通过 `packed-refs` 机制对其中一部分引用进行整合。LWN 在报道 Android 仓库拥有超过 800,000 个引用、引用密集的仓库可能面临代价高昂的查找操作时,引用了 Git 的 reftable 文档。reftable 以二进制格式存储引用,旨在减少空间占用并支持更快的访问。Git 2.45 使创建基于 reftable 的仓库成为可能,但所提供的文档并不能证明 reftable 已经是默认设置。

其潜在好处主要是运维层面的,而不是大多数用户能够直接看到的:大型仓库或许能够更高效地处理引用。潜在风险则出现在边缘环节,即其他程序在不使用 Git 本身的情况下读取或写入仓库。LWN 指出,libgit2 可能带来兼容性问题,随后报道 Patrick Steinhardt 曾表示,libgit2 已经获得 reftable 支持,并在 8 月默认启用了 SHA-256 支持。这是一条归因于开发人员的更新;它支持 libgit2 正在为此做准备的判断,但并不能证明每一个嵌入 libgit2 的应用程序都已经发布所需的支持。

第三个提议的变更,是将 Rust 设为构建 Git 的必需条件。LWN 报道,Git 已经尝试支持 Rust,但一直不愿要求必须安装可用的 Rust 编译器。如果这一提议最终落地,没有合适 Rust 工具链的平台将无法构建新版 Git。所提供的资料没有说明哪些平台会受到影响、要求使用哪些编译器版本,也没有说明下游发行版是否会提供替代方案。因此,这些证据能够支持该提议的存在及其可能后果,但不能构成完整的可移植性评估。

这些讨论提示我们,需要区分改变仓库的对象格式与重写普通提交历史。所提供的资料包没有足够的原始文档,可以回答是否必须对每个 SHA-1 仓库执行强制推送、托管服务提供商将如何提供迁移后的仓库,或者混合格式的子模块会如何运作。这些问题应继续保持开放,而不应依据零散的评论作出回答。现有证据能够确定的是,SHA-256 支持已经存在,大版本规划与兼容性工作相关,而代码托管平台和工具生态的准备程度则是核心限制因素。

对于负责维护重要仓库的读者而言,直接的影响是盘点依赖项,而不是假定安装 Git 3.0 会完全透明、毫无影响。盘点范围包括托管仓库服务提供商、CI 系统、备份与归档工具、代码审查软件、IDE 集成,以及 libgit2 等库。团队还应区分 SHA-256 或 reftable 的本地试验,与一项会改变协作者和服务之间交换仓库数据方式的协同迁移。所提供的资料没有提供通用的迁移流程,因此任何部署计划都应等待相关服务提供商和工具的文档发布。

最重要的注意事项是时间安排。LWN 的更新给出了具体的发布顺序,但资料包中没有独立的发布公告,也没有 Git 项目的一手文档予以确认。同样,从可见的 LWN 署名可以明确看出,来源的准确发布日期是 2026 年 9 月 18 日;而资料包的生成日期较晚,不应被视为文章发布日期。最稳妥的理解是,Git 3.0 是一个已经确定方向、并正在进行大量准备工作的规划,而不是一次已经完成的过渡,其兼容性和时间表尚未最终确定。