Git 项目发布了 Git 2.55，为世界上使用最广泛的版本控制系统引入了性能增强、工作流程改进和新的实验性命令。
对于 Linux 用户而言，最显著的特性是对 Git 内置文件系统监视器守护进程的支持。此前，Git 内置的 FSMonitor 守护进程仅适用于 macOS 和 Windows 系统。Git 2.55 通过添加 Linux 支持并利用内核的 inotify 子系统来跟踪文件系统变更，从而改变了这一现状。
预计这将加快git status大型代码库等场景下的命令执行速度。Git 不再扫描整个工作树，而是向监控守护进程查询文件更改信息。
针对 Linux 系统的一个特殊考虑是，该实现方式为每个目录使用一个 inotify 监视。对于非常大的仓库，可能需要增加此fs.inotify.max_user_watches限制。FSMonitor 对网络挂载仓库的支持仍然是可选的。
Git 2.55 还引入了对仓库维护的改进，尤其对于大型项目而言。该版本支持使用 git repack 编写增量多包索引链git repack --write-midx=incremental。
Git 2.55 还引入了一个新的实验性git history fixup <commit>命令，允许用户将暂存的更改直接应用到较早的提交，并在其上重放后续提交。
这提供了一种比 ` git commit --fixupand`git rebase --autosquash工作流程更直接的替代方案。然而，该命令仍处于实验阶段且较为保守；如果应用暂存的更改会导致冲突，Git 会中止操作，而不是让用户陷入复杂的重写状态。
此版本还改进了配置钩子。Git 2.54引入了基于配置的钩子，允许在 Git 配置中定义钩子，而不仅仅是将其作为可执行文件放在钩子目录中。现在，Git 2.55 进一步扩展了这一功能，使兼容的配置钩子能够并行运行。
例如，如果独立提交前检查（例如代码检查和单元测试）被标记为可并行执行，则可以并发运行。而依赖于共享状态的钩子（例如检查索引或工作树的钩子）仍然串行运行。
性能提升还体现在可达性位图的生成上，使 Git 能够在重新打包等操作期间更快地响应对象可达性查询。版本发布报告中引用的基准测试表明，在一个大型代码库中，位图生成时间从约 612 秒减少到 294 秒。
部分克隆和过滤打包工作流受益于增强功能。在 Git 2.55 中，此模式可以与诸如` <filter>`、 `<filter> `、 git pack-objects --path-walk`<filter>` 等过滤器结合使用。blob:noneblob:limit=<n>tree:0
除了上述改动之外，还包含一些其他细微的更改。更具体地说，Git 现在默认屏蔽远程边带输出中的大多数终端控制字符，从而降低在执行诸如 `git checkout` 之类的操作时出现令人困惑或意外的终端行为的风险git push，同时仍然允许使用 ANSI 颜色序列。
此外，该git checkout -m命令现在更安全了。在切换分支并进行本地编辑时，Git 会使用内部自动暂存机制来保存冲突的更改，允许稍后重新应用这些更改，而无需立即解决。
此版本新增了对推送至远程组的支持。此功能简化了将同一分支发布到多个远程服务器（例如主主机和镜像服务器）的操作。用户可以定义一个远程组，然后使用单个命令将代码推送至所有远程服务器。
对于依赖可视化历史记录输出的用户，git log --graph现在新增了一个--graph-lane-limit=<n>选项。该选项可以限制图表的宽度，并将超出限制的泳道替换为空白~，从而使宽阔的历史记录在终端中更易于阅读。
最后，Git 2.55--max-count-oldest=<n>为 ` git commit`git rev-list及其git log命令族引入了一个选项。与-n选择最新提交的选项不同，此选项选择指定范围内最旧的提交，且不进行 shell 端后处理。
