导读：Git 2.55发布，开发者必须要知道一点的是：Rust 现已被默认启用了。

Git 2.55 已经于 6 月 29 日正式发布，其中最吸引开发者注目的一点是：Rust 现在已经默认启用。

在此版本发布之前，你需要手动启用它WITH_RUST=1。而现在你可以通过手动禁用它NO_RUST=1。如果你维护着一个从源代码编译 Git 的 CI 流水线，并且对此毫不知情，那么下次容器重建时，可能会遇到意想不到的问题。

除了 Rust 的更改之外，此版本还新增了git history fixup并行钩子执行和通过 inotify 实现的 Linux fsmonitor 支持——每一项都值得了解。

Rust 默认启用——Git 3.0 将强制启用

WITH_RUST从 ` ` 到`` 的重命名NO_RUST。虽然只是文本上的细微改动，却对实际操作产生了重大影响。

任何在未明确禁用 Rust 的情况下编译 Git 的构建流水线，现在都需要一个可用的 Rust 工具链。这包括基于发行版基础镜像构建的 Docker 镜像、嵌入式工具链，以及基础设施团队维护的任何自定义 Git 打包。

选择不使用Rust的方法如下：

# Makefile buildsmake NO_RUST=1# Meson buildsmeson configure -Drust=disabled

如果你使用发行版中预编译的软件包，可能不会注意到任何变化——软件包维护者会在规范层面处理这个问题。但如果自行构建 Git 版本，现在就应该检查你的编译流水线了。

Git 3.0 计划于 2026 年底发布，届时将彻底移除 NO_RUST 的选项。Rust 将成为强制性使用的语言，这一点已毋庸置疑。

社区的反应果然不出所料。由 XLibre Xorg 分支的开发者领导的 Libre-WD40 项目在官方版本发布几天后就搞出并发布了去锈版的 Git 2.55。这个名字是个双关：WD-40 可以去除“锈迹”。

从技术角度来看，这展示了开源的潜力，很有意思，但它并非官方 Git 项目的可靠长期替代方案。如果你的组织确实担心 Rust 工具链的依赖性，那么 NO_RUST 标志的存在自有其道理。

嗯，趁它还在的时候赶紧用吧。

Git 历史记录修复：只需一条命令即可完成两条命令

git history 命令在 Git 2.54 中以实验性方式引入。在 2.55 版本中，它新增了一个 fixup 子命令，将传统的两步 fixup 工作流程简化为一步。

旧的工作流程： git commit 然后执行 git rebase 交互式自动压缩。

新的工作流程：暂你的更改，然后使用目标提交的 SHA 运行 git history fixup 命令，立即完成。

该命令会将暂存的更改合并到目标提交中，并自动重放所有后续提交。更重要的是，它还会更新包含已修复提交的每个本地分支——这使它在堆叠分支工作流程中非常实用，因为在这种工作流程中，单个修复通常需要手动变基多个分支。

一个重要提示是：git history fixup 仍处于实验阶段。它需要一个工作仓库（不支持裸仓库），并且在合并冲突时会干净利落地中止，而不是像有状态重写那样让你在操作过程中卡住。这种中止行为实际上比交互式变基更安全，因为交互式变基可能会导致你在变基过程中处于 HEAD 分离状态。

平行钩：同时进行棉絮收集和测试

基于配置的钩子已在 Git 2.54 中引入。Git 2.55 添加了可选的并行执行功能。如果你有独立的推送前钩子（例如代码检查器和单元测试运行器），它们现在可以同时运行。在任何钩子上配置 parallel = true，并将 jobs = -1 设置为使用所有 CPU 核心即可。

并非所有钩子都能并行化——pre-commit 和 prepare-commit-msg 被明确排除在外，因为它们共享提交消息缓冲区。但对于不共享资源的 pre-push 和 post-merge 钩子来说，这可以带来直接的性能提升，无需任何代码更改。

Linux fsmonitor：在大仓库上 git status 命令运行速度很快

内置的 fsmonitor 守护进程已在 Git 中存在多个版本，但之前仅支持 macOS 和 Windows。Git 2.55 通过内核的 inotify 子系统添加了对 Linux 的支持。

使用两条命令即可启用：`git config core.fsmonitor true`，然后运行 `git fsmonitor--daemon start`。该守护进程会监视文件系统的更改，而不是在每次执行命令时都遍历目录树。在官方 Git 2.55 版本亮点中引用的一项基准测试中，位图生成时间从 612 秒缩短至 294 秒。在一个包含 50 万个文件的仓库中，守护进程启动后，`git status` 命令的响应时间从几秒缩短至几乎瞬间完成。

Linux 单体仓库团队需要注意一点：inotify 默认的每个用户监视数量上限为 8,192 个。大型仓库会很快达到这个上限。你可以通过 sysctl 命令将 `fs.inotify.max_user_watches` 设置为 524288 来提高上限——将其添加到 `/etc/sysctl.conf` 文件中即可使其永久生效。

还有哪些变化？

Git 2.55 引入了增量 MIDX 重打包功能，它会将新层添加到多包索引中，而不是重写整个索引——这对 Git 托管服务商和大型单体仓库来说至关重要。对于只检出大型代码树中一小部分的仓库，稀疏检出性能提升了约 50%。这些改进在大规模应用中意义重大，但不太可能直接影响大多数开发工作流程。

Git 2.55 还扩展了对 hook 执行行为的支持，并继续为未来版本中更高级的 hook 管理奠定基础。

立即升级还是准备退出？

Git 2.55 版本发布后，开发者们需要做出一些决定。

如果你是从源代码构建 Git：请在 3.0 版本发布之前，将 Rust 添加到你的工具链中，或者设置 NO_RUST=1。如果你使用的是打包好的 Git：请在 Linux 系统上启用 fsmonitor，并在下次重构时尝试使用 git history fixup。并行钩子配置只需五分钟即可完成，并且可以节省每次推送的时间。

Rust 在 Git 中的应用已不再是争论的焦点，而是发展的方向。现在唯一的问题是，是现在就做好准备，还是等到 3.0 版本发布时再手忙脚乱？

作者：万能的大雄