自2014年git 2.0发布,至今已有12年。
这12年里,你的手机从iPhone 6换到了iPhone 17,编程语言从Java 8升级到了Java 21,连JavaScript框架都换了五六茬——但Git,还是2005年那个用C语言写的老古董。

不是它不想变。是它的用户太多了,牵一发而动全身。

但这次不一样了。Git 3.0,这个酝酿了12年的重大版本,真的要在2026年来了。
官方计划是在2026年底发布(2025年Git贡献者峰会上已经正式讨论了发布时间表)。

SHA-256全面替换SHA-1、Rust正式成为强制依赖、分支操作提速22倍……这可能是你职业生涯中,Git最大的一次变革。

01 最大亮点:SHA-256取代SHA-1,代码仓库更安全

Git从诞生起,就一直用SHA-1哈希算法来给每个commit生成唯一的ID。但SHA-1早已被证明存在安全漏洞——2017年,研究人员成功实施了“SHAttered”攻击,证明了实际可行的SHA-1哈希碰撞

虽然Git后来在2.13.0版本中采用了强化版的SHA-1,但根本缺陷依然存在。

Git 3.0将默认使用SHA-256哈希算法,彻底解决这个安全隐患。

据主导这项工作的开发者Brian m. carlson估计,整个迁移需要200到400个补丁,目前大约完成了100个。工作量巨大,但Git团队的目标是在3.0版本时让整个生态系统(GitHub、GitLab、CI/CD工具等)都能支持SHE-互操作。

对普通开发者有什么影响?

  • 你用git init新建一个仓库,默认就用SHA-256
  • 旧的SHA-1仓库继续能用,Git会保证两者兼容
  • 安全性大幅提升,代码仓库更难被篡改

一句话总结:你的代码更安全了,而且你几乎感知不到变化。

02 Rust正式成为强制依赖:Git变得更稳、更安全

Git的核心代码一直是C语言写的。C语言性能强,但内存管理全靠开发者手动操作,一不小心就会出bug——缓冲区溢出、悬空指针、内存泄漏……这些隐患让无数程序员熬夜找bug。

Git 3.0将把Rust作为强制依赖,开始逐步用Rust重写部分核心模块。

Rust编译器在编译阶段就能杜绝内存访问错误,这也意味着安全漏洞大幅减少。在早期实验中,用Rust优化的xdiff组件性能提升了5%-19%。

Git从2.49版本开始就提供了可选的Rust构建支持,到了3.0,它会成为必要依赖。

话说回来,如果你是从源码编译Git,可能需要安装Rust环境。不过对大多数通过包管理器(如apt、brew)安装的用户来说,基本无感。

03 Reftable:上万分支,push速度飙升18倍

这是Git 3.0中最直观的性能升级

先解释一下背景:Git里每个分支和标签都是一个“引用”(ref)。目前Git把每个引用存成一个单独的文件(refs/heads/xxx)。项目大了之后,分支成千上万,文件系统就扛不住了。

访问慢、占用磁盘多、Windows/macOS上大小写不敏感的问题……都源于这种古老的设计。

Git 3.0将启用全新的引用存储格式—— reftable。简单说,就是把所有引用存进一个结构化的二进制文件里,查询快、更新原子化。

性能有多强? 在一个包含10,000个引用的仓库中:

  • git fetch 操作速度提升 22倍
  • git push 操作速度提升 18倍-23

而且reftable彻底解决了Windows/macOS上的大小写问题(比如feature/Login和feature/login终于可以共存了),也支持原子化更新,多人同时push时不会出现竞态条件-。

大型单仓(monorepo)的团队,这个更新会直接改变你的日常体验。

04git init默认分支从master改为main

这个改动可能你已经从GitHub、GitLab等平台上感受到了。GitHub早在2020年就把新仓库的默认分支改成了main。

Git 3.0终于把这一改动写进了上游:运行git init初始化仓库时,默认创建的是main分支,不再是master-45。

对你有什么影响?

  • 新项目自动就是main,不用手动改
  • 老项目继续用master,不受影响
  • 如果你的脚本依赖默认分支名,建议调整一下,或开始兼容双命名
05 告别git rebase -i?新命令git history要来了

我写过很多次git rebase -i的教程。但说句实话,交互式rebase对新手确实不太友好:界面不直观、容易误操作,修改历史commit消息这种常见操作,步骤略显繁琐。

Git 3.0计划引入一个新命令:git history。

  • git history reword :直接修改某个历史commit的消息,不用进交互式rebase
  • git history split :把一个包含多个改动的commit拆分,解决许多场景下的灵活应用

这个设计参考了Jujutsu和Mercurial等现代版本控制系统的理念——让Git从“告诉系统怎么做”,变成“直接表达你想做什么”

目前这个命令还在开发中,可能在Git 2.54版本左右落地。如果顺利,3.0会正式成为标配功能。

写在最后:Git 3.0,你需要干什么?

影响评估表:

新特性

影响范围

你需要做什么?

SHA-256

安全性

基本无感,放心升级

Rust依赖

编译方式

通过包管理器装Git的开发者无影响

Reftable

高性能

大型单仓推荐重测,尽早拥抱新格式

default分支名

新仓库

有CI/CD脚本的建议手动检查并适配

git history

用户体验

期待未来用得顺手

放心的是,Git 3.0会保持良好的向后兼容性。你的旧项目、旧脚本、旧习惯,大部分不用动。

但如果你的工作流依赖特定分支名,或者团队有大量脚本,现在就可以开始:去GitLab/GitHub等平台的设置里,提前读一读关于SHA-256和reftable的实验性支持文档,做好内部评估。

关注我,这份《Git 3.0新特性速查表》,可以存下来。评论区留言“Git 3.0”,我会私信发给你。