源代码管理系统 Git（Git）处于全球开发流程的核心，因此其变更尤其是不兼容变更备受相关开发者关注。预计9月底左右发布的 Git 2.56 目前已提供候选版本（release-candidate）。这并非最具颠覆性的版本，但紧随其后的版本可能是期待已久的 Git 3.0。Git 2.56 包含超过700个非合并提交，带来了一些改进，但不会改变大多数用户的 Git 使用体验。

Git 源代码管理系统是全球开发流程的核心，其变更尤其是不能兼容的变更备受开发者关注。Git 2.56 预计九月底发布，目前已有候选版本。它并非最震撼的发布，但紧随其后的可能是期待已久的 Git 3.0。

Git 2.56 中有什么

2.56 包含逾 700 个非合并提交，带来若干改进，但不会根本改变大多数用户的体验。其中一个潜在功能是给仍实验性的 git history 工具箱添加 drop 子命令：git history drop _commit-id_，可从当前分支历史移除指定提交并重放其后所有提交，更易撤消问题提交，但仍拒绝对含合并提交的历史操作，多数仓库不可用。

git status 现会建议用 git pull 更新落后跟踪分支的分支，不过即使分支落后于未获取的远程跟踪分支，它仍显示“up to date”。

git refs 命令用于底层操作引用，2.56 新增 create、delete、update、rename 子命令，功能如名所示。

若干易用性微调：git branch 新增 --delete-merged 选项，移除已合并到远程跟踪分支的本地分支；用 git branch -d 删除正用于二分查找的分支会失败并给提示；配置锁失败会重试；git add 新 --resolved 选项仅添加已解决合并冲突的文件。

其余是常规缺陷修复、重构和性能改进。2.56 看来稳健，但也显露出项目将重要工作留给了未来，引出接下来的问题。

2.56 之后？

九月初，Git 维护者 Junio Hamano 询问社区下一个版本该是什么：直接推出酝酿已久的 3.0，还是先发若干 2.x 版本？

此事关键，因为 3.0 将包含一些可能让用户升级前犹豫的兼容性中断。其中最显著的是默认改用 SHA-256 哈希函数，而非 Git 自初代使用的 SHA-1。SHA-1 早被视为弱算法，而哈希用于标识仓库中每个对象（文件、目录树、提交）并验证提交链，若被攻破，可能难以察觉地修改历史。

Git 长期包含针对已知 SHA-1 攻击的防御，眼下少有人严肃担忧仓库被篡改，但转向更安全哈希确有意义。

SHA-256 的非实验性支持自 2023 年 2.42 版起存在，但与旧仓库互操作的适配耗时更久。迟迟未默认启用的主要顾虑是大型托管站点的支持。GitLab 自 2024 年支持，Forgejo 也支持，但 GitHub 仍缺席。发布会创建 GitHub 不兼容仓库的 Git 版本令人忧心。虽不清楚 GitHub 何时支持，但 GitHub 员工、SHA-256 过渡关键开发者 brian m. carlson 回应 Hamano 称相关消息将至，且下一版定为 3.0 或许是最好选择。

carlson 还提出另一项希望在 3.0 前加入的改动：Git 一向将十六进制对象 ID 作小写字符串处理，但也接受大写 ID，导致 f00f00 与 F00F00 看似不同实则相同，曾引发 bug 和安全漏洞。他希望改为只接受小写 ID，这应不会困扰多数用户，但难免有人依赖该行为。

另一项等候 3.0 的重要改动是切换到 reftable 机制。ref（引用）是名称与仓库对象的关联，分支、标签、远程均属 ref。Git 目前默认将每个 ref 存为 .git/refs/ 下的文件，虽有 packed-refs 机制整合，但 ref 数量增长后效率骤降。据文档，Android 仓库含超 80 万 ref，此规模下查找或判断指向某提交的 ref 开销巨大。

Git 2.45 加入 reftable 作为更高效存储，它是优化空间与访问速度的二进制文件。此后可创建使用 reftable 的仓库，但从未作为默认。切换对用户无可见影响（除性能提升），但可能影响其他访问 Git 的软件包，carlson 提及 libgit2 的隐忧。

不过 libgit2 不会成障碍：Patrick Steinhardt 表示已为其添加 reftable 支持，且 SHA-256 默认支持已于八月启用，故 libgit2 已就绪。

最后 carlson 提到 Rust 问题。项目已添加 Rust 代码试验支持，但犹豫将 Rust 列为构建必需。3.0 预计改变此点，此后无可用 Rust 编译器的平台将无法升级。

列出顾虑后，carlson 认为它们不应阻碍 3.0：

我认为任何未在 SHA-256（及本地仓库软件的 reftable）上极超前者不值得考虑。例如 JGit 和 Gitoxide 至少一年前就被告知 SHA-256 将随 Git 3.0 而来（是我告知的）。类似，我不了解有谁在认真为不支持 Rust 的平台做支持，故也不认为该是阻塞。

他因而结论将下一版定为 3.0 最佳。

实际动向尚未公开，待 Hamano 决定。他指出“这不是人气竞赛，也不是民主”。帖子发出近两周，无人强烈反对迈入 3.x 时代、抛弃部分早期设计（但使用 SHA-1 且无 reftable 的仓库将继续受完全支持）。若 2026 年未发 3.0，不久后也必现身。

部分用户质疑 SHA256 迁移成本与平台支持滞后，少数人反感强制推广 Rust，同时对底层存储优化和新命令抱有期待。

质疑 SHA256 迁移需重写历史且平台支持滞后

• 用户担心从 SHA1 转向 SHA256 需要强制推送并重写全部历史，反而成为安全漏洞来源；另有指出 GitHub 因核心系统僵化在 SHA256 与 IPv6 上进展迟缓，且 BitBucket 同样未支持（较多人）。
• > 难怪 GitHub 在 SHA256 上拖后腿，估计核心系统改不动了，只能边缘修补（@globular-toast）

认为强制推广 Rust 是毫无意义的一刀切

• 有评论批评为了用 Rust 而强制所有人采用，是无理且强加负担的做法（少数人）。
• > 可惜他们为了 Rust 而 Rust，这种无理要求现在强加给了每个人（@coliveira）

希望 Git 弃用慢速文件并修复不良默认

• 用户询问在引入 reftable 后是否还有计划彻底弃用慢文件改用数据库，还是仅留给后 Git 竞争者；同时有人期待 Git 3.0 能修正糟糕的默认配置（少数人）。
• > 既然能用 reftable 替代旧文件机制，还有别的弃用慢文件用数据库的打算吗（@eviks）

欢迎新增 git add --resolved 命令

• 单个用户认为该命令很实用，会开始使用（少数人）。