00:00:00
资料库 · Git 版本演进（2.35–2.55）
第 ② 卷，条目 21–40。全部来自 github.blog 的 Highlights 系列，作者绝大多数是 Taylor Blau（Git 核心贡献者、GitHub 的 Git 团队成员）。
这一卷别顺着读。 20 篇发布说明连着读会睡着，而且记不住。它的用法是查：
git --version看你现在什么版本- 找到你的版本到目标版本之间那几条
- 只扫「新命令」和「行为变化」两类，其他跳过
按版本从旧到新排，方便按区间取。2.53 不在列表里——GitHub 的 Git 分类页面上没有这一版的 Highlights，不是我漏了。
关于 Git 的发布节奏
Git 大约每季度一个小版本（2.x），已经稳定这个节奏十几年了。这个节奏有两个对使用者有实际意义的性质：
- 单版本的变化量很小。 所以跨 4–5 个版本升级的风险，通常比一次大版本升级低得多。
- 破坏性变化几乎不发生。 Git 的兼容承诺极强，代价是一批明显更好的行为只能作为可选配置存在（见第一卷第 15 条）。所以升级 Git 之后你的体验通常不会变好——你得去把新配置打开。 这一卷真正的价值就在这里：告诉你有哪些开关可以打开。
2022 年：稀疏索引与后台维护成型
21. Highlights from Git 2.35
来源：Taylor Blau，GitHub Blog，2022 年 1 月 24 日。
读它解决什么：确认 2.35 的内容，本卷的起点版本。
要点：
- Git 2.35 发布说明，2022 年 1 月
- 本卷收录的最早版本
我的补充：2.35 里对日常影响最大的是 merge.conflictStyle = zdiff3 这个新选项。它让冲突块里多显示共同祖先那一段，解冲突时你能看到"两边各改了什么"而不是只看到两个结果。我认为这是近几年 Git 加的最实用的一个东西，而它默认关着。
bash
git config --global merge.conflictStyle zdiff3如果你的 Git ≥ 2.35（2022 年之后的发行版基本都是），现在就设上。
22. Highlights from Git 2.36
来源：Taylor Blau，GitHub Blog，2022 年 4 月 18 日。
读它解决什么：2.36 的变化汇总。
要点：
- Git 2.36 发布说明，2022 年 4 月
我的补充：这一版里 git log --since 相关的历史遍历行为有调整，另外 core.fsyncObjectFiles 那套磁盘同步配置开始重构（后来演化成 core.fsync）。
后者值得说一句，因为它影响一类真实故障：Git 默认不对每个对象文件做 fsync，机器断电时可能留下损坏的对象。桌面开发机上这是合理的取舍（性能优先，坏了重新 clone），但如果你在服务器上放唯一一份仓库（自建 Git 服务、CI 缓存），应该把 core.fsync 调到包含 objects 和 refs。我见过一次机房断电后自建 Git 仓库出现 error: object file ... is empty 的情况，就是这个原因。
23. Highlights from Git 2.37
来源：Taylor Blau，GitHub Blog，2022 年 6 月 27 日。
读它解决什么：2.37 的变化汇总。
要点：
- Git 2.37 发布说明，2022 年 6 月
我的补充：这一版有两个我经常用到的东西。
push.autoSetupRemote：新分支第一次 push 不用再打 --set-upstream。就为这一个配置也值得升到 2.37：
bash
git config --global push.autoSetupRemote true内置文件系统监视器（core.fsmonitor = true） 在这一版趋于可用。它让 Git 通过操作系统的文件变更通知（macOS 的 FSEvents、Windows 的 ReadDirectoryChangesW）来判断哪些文件动过，而不是每次 git status 都 stat 一遍工作区。在几万文件的仓库上，git status 能从几秒降到几十毫秒。
注意 Linux 上这个功能不可用（内核侧没有等价的高效接口），这是个常见误解。Linux 上大仓库慢就得靠 sparse-checkout 那条路（见第三卷）。
24. Highlights from Git 2.38
来源：Taylor Blau，GitHub Blog，2022 年 10 月 3 日。
读它解决什么：2.38 的变化汇总。
要点：
- Git 2.38 发布说明，2022 年 10 月
我的补充：这一版把 Scalar 收进了 Git 本体（Scalar 的来历见第三卷第 46 条）。Scalar 是一个"帮你把大仓库配置好"的包装器：它一次性把 partial clone、sparse-checkout、commit-graph、fsmonitor、后台 maintenance 全部配上，省掉你逐个研究。
用法就一句：
bash
scalar clone <url>如果你要 clone 一个 GB 级的仓库，用这个而不是 git clone。我的经验是在大型 monorepo 上首次可用时间能差几倍。
git maintenance 这条线在这一版也继续完善。git maintenance start 会注册一个后台任务（cron / launchd / Windows 计划任务），定期做 gc、写 commit-graph、prune。个人开发机上建议开——它解决的是"仓库用久了莫名变慢"这个问题（见第一卷第 18 条）。
25. Highlights from Git 2.39
来源：Taylor Blau，GitHub Blog，2022 年 12 月 12 日。
读它解决什么：2.39 的变化汇总。
要点：
- Git 2.39 发布说明，2022 年 12 月
我的补充：这一版 git blame 有可用性改进，另外 git grep 等命令的性能有优化。
借这一条说个 git blame 的实战技巧，因为它是最容易被误用的命令之一：默认的 git blame 会把"格式化整个文件"这类提交显示成所有行的作者，完全掩盖真实的改动者。解决办法：
bash
# 忽略只有空白变化的提交
git blame -w
# 检测行的移动/复制（跨文件也算）
git blame -w -C -C -C
# 忽略指定的批量格式化提交
git blame --ignore-rev <sha>更彻底的做法是在仓库根放一个 .git-blame-ignore-revs 文件，把所有批量格式化的提交 hash 列进去，然后 git config blame.ignoreRevsFile .git-blame-ignore-revs。GitHub 网页版的 blame 也认这个文件。任何做过一次全仓库 Prettier/gofmt 的项目都该配上。
2023 年：稳定期
26. Highlights from Git 2.40
来源：Taylor Blau，GitHub Blog，2023 年 3 月 13 日。
读它解决什么：2.40 的变化汇总。
要点：
- Git 2.40 发布说明，2023 年 3 月
我的补充：这一版偏内部改进，对日常使用影响不大。
这种"没什么亮点"的版本恰恰说明了 Git 的成熟度。对照着看：一个每个版本都有大变化的工具，说明它还没定型，你的知识会持续贬值；Git 相反，你 2015 年学的东西现在还全都有效。这是选择基础设施工具时被低估的一个指标。
实操建议：发布说明里没有你在意的东西，就跳过这一版，等下一个有实质变化的版本再升。没必要追每一个小版本。
27. Highlights from Git 2.41
来源：Taylor Blau，GitHub Blog，2023 年 6 月 1 日。
读它解决什么：2.41 的变化汇总。
要点：
- Git 2.41 发布说明，2023 年 6 月
我的补充：这一版在对象库和 packfile 侧有优化，属于"升上去就自动变快，不用改任何东西"的那类改进。
这类改进值得单独说一下它为什么占了 Git 发布说明的大半：Git 的用户量极大且场景差异极大（从几十个文件的个人项目到 Windows 那种几百万文件的仓库），所以 Git 团队的工作重心长期在性能而不是新功能。GitHub 和微软的 Git 团队尤其如此——他们服务的是极端规模的用户，那些优化最后惠及所有人。
从使用者角度，这意味着定期升级 Git 是有实际收益的，即便你看不到任何新命令。我的做法是跟着系统包管理器走，一年内至少升一次。
28. Highlights from Git 2.42
来源：Taylor Blau，GitHub Blog，2023 年 8 月 21 日。
读它解决什么：2.42 的变化汇总。
要点：
- Git 2.42 发布说明，2023 年 8 月
我的补充：这一版有 packfile 复用相关的服务端优化（对自建 Git 服务的人有意义），以及一批命令的选项补齐。
借这条说一个和"服务端"有关的判断：如果你在自建 Git 服务（Gitea、GitLab、裸仓库 + SSH），服务端的 Git 版本比客户端更值得关注。clone/fetch 的大部分工作在服务端完成，服务端版本旧就意味着所有客户端都吃不到优化。而且服务端 Git 往往是最容易被忘记升级的——它跑在容器里，装好之后没人再碰。
检查办法：ssh git@your-host git --version（如果开了 shell）或者看容器镜像的 tag。GitLab / Gitea 的发布说明里会写捆绑的 Git 版本。
29. Highlights from Git 2.43
来源：Taylor Blau，GitHub Blog，2023 年 11 月 20 日。
读它解决什么：2.43 的变化汇总。
要点：
- Git 2.43 发布说明，2023 年 11 月
我的补充：这一版继续在 sparse-checkout 与 partial clone 那条线上完善（这两个特性从 2.25 前后开始，一直迭代到现在，见第三卷）。
一个横跨多个版本的观察值得在这里点出：Git 的大特性从不是一次做完的。sparse-checkout、partial clone、reftable、bundle URI 这几个，每一个都跨了十几个版本逐步稳定。这直接影响你怎么读发布说明——看到一个特性别急着上，先看它是"引入"还是"完善"。引入阶段的特性（通常标 experimental）在生产环境用会踩坑；等到发布说明里不再提它，才是真的稳了。
判断办法：在 github.blog/open-source/git/ 里搜这个特性名，看它被提过几次。提了五六次还在提的，就是还在迭代。
2024 年：引用后端与命令行界面翻新
30. Highlights from Git 2.44
来源：Taylor Blau，GitHub Blog，2024 年 2 月 23 日。
读它解决什么：2.44 的变化汇总。
要点：
- Git 2.44 发布说明，2024 年 2 月
我的补充：从 2.44 开始的这几版，主线是引用存储后端的重写（reftable，见下一条）和命令行界面的现代化。
这里说个和引用有关的、任何规模都会碰到的问题：Git 默认把每个引用存成一个文件（.git/refs/heads/xxx），分支多了之后会被"打包"进 .git/packed-refs 这个单一文本文件。问题是 packed-refs 的更新是整文件重写，所以在有几万个引用的仓库上（想想那些每个 PR 都留一个引用的 CI 仓库），每次更新引用都要重写一个几 MB 的文本文件，而且要拿全局锁。
征兆是 git fetch 或 git push 莫名很慢，且 .git/packed-refs 很大。临时缓解：git pack-refs --all 加上 git config fetch.prune true 定期清理。根治要等 reftable。
31. Highlights from Git 2.45
来源：Taylor Blau，GitHub Blog，2024 年 4 月 29 日。
读它解决什么：2.45 的变化汇总，reftable 后端首次可用的版本。
要点：
- Git 2.45 发布说明，2024 年 4 月
- 这一版起可以选用新的 reftable 引用存储后端
我的补充：reftable 是上一条那个问题的正解。它来自 JGit / Gerrit，用的是一种支持增量追加、二分查找的二进制格式，替代 loose refs + packed-refs。效果是引用的读写都变成对数级，几十万引用的仓库也不会卡。
试用方式（新仓库）：
bash
git init --ref-format=reftable
# 确认当前仓库用的是哪种
git rev-parse --show-ref-format别急着在生产仓库上切。 刚可用的阶段，所有直接读 .git/refs/ 的第三方工具都会瞎掉——一些 CI 脚本、IDE 插件、状态栏工具是直接读文件而不是调 git 命令的。判断能不能上的标准很简单：你的工具链里有没有东西在 cat .git/refs/heads/... 或者 ls .git/refs。有就先别切。
我自己的态度是：个人小仓库无所谓（本来也不慢），真正需要它的是那些引用爆炸的大型 CI 仓库，而那种仓库通常也是工具链最复杂、最不敢动的。所以这个特性的推广会比较慢。
32. Highlights from Git 2.46
来源：Taylor Blau，GitHub Blog，2024 年 7 月 29 日。
读它解决什么：2.46 的变化汇总，git config 子命令化的版本。
要点：
- Git 2.46 发布说明，2024 年 7 月
- 这一版起
git config提供get/set/unset/list等子命令
我的补充：git config 的老界面是靠参数形态区分动作的，这是 Git 命令行设计里最糟的一处：
bash
git config user.name # 一个参数 = 读
git config user.name "Alice" # 两个参数 = 写
git config --unset user.name # 靠 flag = 删问题在脚本里很实际：变量为空时行为会静默改变。git config user.name "$NAME"，如果 $NAME 是空字符串，你以为在写值，实际上……取决于引号有没有生效。忘了引号就变成了读操作，脚本继续跑下去，配置没写上但也没报错。
新界面把动作显式化了：
bash
git config get user.name
git config set user.name "Alice"
git config unset user.name
git config list新脚本一律用新形式。 老形式不会删（Git 的兼容承诺），但它值得从你的肌肉记忆里去掉。注意这需要 Git ≥ 2.46，写给别人用的脚本要考虑目标环境的版本。
33. Highlights from Git 2.47
来源：Taylor Blau，GitHub Blog，2024 年 10 月 7 日。
读它解决什么：2.47 的变化汇总。
要点：
- Git 2.47 发布说明，2024 年 10 月
我的补充：2024 年这几版里 reftable 和 git config 是主线，其余多为增量优化。
借这条讲一个"读发布说明"的方法，因为这一卷的价值全在这上面。Git 的 Highlights 文章通常有三类内容，只有第三类需要你行动：
- 性能优化 —— 升级即得，不用管
- 新命令 / 新选项 —— 记下来，等碰到对应问题时想起它
- 默认行为变化 / 新配置 —— 必须处理
第三类在 Highlights 里往往埋在中间，措辞是"now defaults to"或"a new configuration"。我的做法是打开页面直接 Ctrl+F 搜 default——命中的地方就是需要注意的。这比通读快得多，而且不会漏掉真正影响你的东西。
2025 年：Git 二十周年
34. Highlights from Git 2.48
来源：Taylor Blau，GitHub Blog，2025 年 1 月 10 日。
读它解决什么：2.48 的变化汇总。
要点：
- Git 2.48 发布说明，2025 年 1 月
我的补充：这一版发布的同期，Git 项目公布了一批安全漏洞（见第三卷第 52 条）——安全公告和版本发布经常是同一周的事，因为修复要随新版本一起放出。
这带来一个实用推论：看到 Git 发布安全公告，别只升一个补丁版本，直接升到当时的最新小版本。 原因是 Git 的安全修复会同时 backport 到多个维护分支（比如同时发 2.48.1、2.47.2、2.46.3……），你要是只升同系列的补丁版，会拿到修复但错过所有其他改进。反正 Git 的兼容性极好，跨小版本升的风险很低。
35. Highlights from Git 2.49
来源：Taylor Blau，GitHub Blog，2025 年 3 月 14 日。
读它解决什么：2.49 的变化汇总。
要点：
- Git 2.49 发布说明，2025 年 3 月
我的补充：这一版之后就是 Git 的二十周年（2025 年 4 月，见第三卷第 59 条）。
借这条说一个从"Git 活了二十年"能学到的、比任何命令都有用的判断：Git 赢下版本控制不是因为它好用（它明显不好用，第一卷第 13 条整篇都在讲它的术语有多糟），而是因为它的数据模型是对的。内容寻址 + 不可变对象 + DAG 这三件事一旦选对，性能、分布式、离线工作、完整性校验全部是自然结果；而界面的糟糕可以靠工具层（GUI、gh、IDE 集成）弥补。
反过来的例子也有：一些设计更"友好"的版本控制系统，因为在数据模型上做了妥协（比如按文件记版本、或者中心化的版本号），最后在分支和合并上付出了不成比例的代价。
这个模式在技术选型里通用：看它的核心模型对不对，界面难看是可以改的，模型错了改不动。
36. Highlights from Git 2.50
来源：Taylor Blau，GitHub Blog，2025 年 6 月 16 日。
读它解决什么：2.50 的变化汇总。
要点：
- Git 2.50 发布说明，2025 年 6 月
我的补充：到 2.50 这个整数版本，Git 的小版本号已经走了 50 个——按季度节奏算，2.0 到 2.50 大约十二年半。
有个和版本号有关的细节值得知道：Git 不会有 3.0，至少不会因为常规演进而有。Git 团队把 3.0 这个号留给了"破坏性变化"，而唯一在讨论中的破坏性变化是从 SHA-1 迁到 SHA-256。
SHA-256 支持其实早就有了（git init --object-format=sha256），但两种仓库之间不能互操作——没有 SHA-1 与 SHA-256 之间的转换层，所以你没法把一个 SHA-256 的仓库推到只支持 SHA-1 的服务端。这是它没被推广的真正原因，不是技术不成熟。
所以现状是：除非你在做实验，别用 SHA-256 仓库。SHA-1 的碰撞风险对 Git 来说已经缓解过（Git 用的是带碰撞检测的 SHA-1 实现，能识别已知的构造性碰撞并拒绝），日常使用不构成实际威胁。
37. Highlights from Git 2.51
来源：Taylor Blau，GitHub Blog，2025 年 8 月 18 日。
读它解决什么：2.51 的变化汇总。
要点：
- Git 2.51 发布说明，2025 年 8 月
我的补充：借这条把"该不该升级 Git"这个问题给一个明确答案，因为这一卷读下来最容易得到的错误结论是"要一直追最新"。
我的实际策略分两层：
个人开发机 —— 跟系统包管理器，一年至少动一次。理由是新配置项（zdiff3、push.autoSetupRemote、branch.sort）确实改善日常体验，而风险接近零。
CI 与服务端 —— 锁版本，只在有安全公告时动。理由完全相反：CI 里的 Git 是脚本的依赖，任何输出格式的细微变化都可能让某个 awk 断掉，而 CI 挂掉的排查成本远高于新特性的收益。锁的办法是在容器镜像里 pin 具体版本，别用 apt-get install git（那会随基础镜像漂移）。
两者的区别本质上是：开发机的 Git 是给人用的，CI 的 Git 是给程序用的。 给人用的要新，给程序用的要稳。
38. Highlights from Git 2.52
来源：Taylor Blau，GitHub Blog，2025 年 11 月 17 日。
读它解决什么：2.52 的变化汇总。
要点：
- Git 2.52 发布说明，2025 年 11 月
我的补充：注意从这一版往后，GitHub 的 Git 分类页面上没有 2.53 的 Highlights——2.52 之后直接跳到 2.54。可能是那一版没写，也可能发在了别的分类下。
这就是"资料库"这种东西的固有局限，我把它明说：任何按来源整理的索引都会有源头本身的缺口。我不去猜 2.53 里有什么（我没读到那篇文章），也不用别处的二手转述凑一条充数。要查 2.53 的完整变化，去看 Git 仓库里的原始发布说明：Documentation/RelNotes/2.53.0.txt，那是所有 Highlights 文章的原材料，而且从不缺版本。
顺带说，那批 RelNotes 文件其实是比 Highlights 更完整的来源——每一版都有，逐条列全部变化。缺点是它是给熟悉 Git 内部的人写的，可读性远不如 Taylor Blau 的加工版。两者配着用：先读 Highlights 建立印象，要确认细节去查 RelNotes。
2026 年：当前版本
39. Highlights from Git 2.54
来源：Taylor Blau，GitHub Blog，2026 年 4 月 20 日。
读它解决什么：2.54 的变化汇总。
要点：
- Git 2.54 发布说明，2026 年 4 月
我的补充：2.54 和下一条的 2.55 是本卷收录截止时（2026-08-20）最新的两版。
如果你现在要给团队定一个 Git 版本基线，我的建议是取当前最新版往前退两个小版本。理由是：最新版发布后的头一两个月，第三方工具（IDE 的 Git 集成、GUI 客户端、CI 镜像）还没跟上，你会遇到一批"Git 本身没问题，但某个工具读不懂新格式"的怪事；退两版则这些都已经消化完了，同时你还在受支持的范围内（安全修复会 backport 到多个维护分支）。
具体到现在：2.54 是个合理的基线选择，2.55 留给愿意踩坑的人。
40. Highlights from Git 2.55
来源：Taylor Blau，GitHub Blog，2026 年 6 月 29 日。
读它解决什么：当前最新版有什么，要不要升。
要点：
- Git 2.55 发布说明，2026 年 6 月
- 本卷收录范围内最新的 Git 版本
我的补充：升级前的检查清单，我每次给团队升 Git 都走这几步：
git --version记下旧版本，出问题要能说清从哪升到哪- 把区间内所有 Highlights 里的
default搜一遍（见第 33 条的方法） - 在一个真实的大仓库上跑一次完整流程：clone、fetch、rebase、push，看有没有输出格式变化
- CI 单独升、单独观察一个迭代，别和开发机同时动
- 检查有没有工具在直接读
.git/里的文件（见第 31 条），有就重点测
第 5 步最容易漏，也最容易出玄学问题。排查方法：在仓库根跑一遍你的日常工具，同时用 strace -f -e trace=openat （Linux）或 fs_usage（macOS）看有谁在直接打开 .git/refs 和 .git/index。
本卷小结：21–25 条是 2022 年（zdiff3、autoSetupRemote、fsmonitor、Scalar 入本体、maintenance），26–29 条是 2023 年的稳定期，30–33 条是 2024 年（reftable、git config 子命令），34–38 条是 2025 年（二十周年、SHA-256 现状），39–40 条是当前版本。真正需要你动手的是第 21、23、32 三条里提到的配置。
上一卷： ① Git 数据模型与内部原理 · 下一卷： ③ Git 规模化、工作流与安全 →