微软工程师介绍了 Git 中一个会导致代码库膨胀的缺陷，修复方案即将推出

本文最初发布于 DEV CLASS。

Git 计算同一文件不同版本差异的方法存在缺陷，可能会使代码库膨胀数倍，导致性能问题并消耗过多的存储空间。

微软高级工程师 Jonathan Creamer 发文 介绍了其团队使用的一个非常大的 JavaScript Git 存储库，一个单体库（一个存储库，存储多个相关的项目）。该库的每月活跃用户数超过 1000 人，代码行数约为 2000 万行。根据 Creamer 的报告，克隆这个存储库消耗了超乎想象的 178GB 磁盘空间。

该团队咨询了 Git 贡献者 Derrick Stolee（曾在 GitHub 工作，现为微软首席软件工程师）。他发现，在比较两个文件名是常用名的文件（本例中为 CHANGELOG.md）时，Git 实际上是在比较来自不同软件包的文件，因此每次提交都会发现很大的差异。

Stolee 向 Git 提交了一个 Pull 请求，添加了他所谓的 “path walk API”，使 Git 能够按路径对对象进行分组，“完全避免了文件名的哈希碰撞”。Creamer 使用新增的-path-walk参数，将git repack命令应用于这个大型存储库，结果库的大小减小到了 5GB。

在 Linux 内核邮件列表上，Stolee 也 发了 关于这个问题的帖子，称 “其主要发现是当前的文件名哈希算法只考虑了路径名的最后 16 个字符，在这样一个范围内自然会发生一些碰撞”。

在另一篇文章中，Stolee 指出：“在我查看的存储库中，按磁盘大小排序的前 100 个文件路径有一个明显的模式：其中 99 个是 CHANGELOG.json 和 CHANGELOG.md 文件...... 本应是一组微不足道的增量，却膨胀到了 20-60MB” 。

Stolee 还举了其他一些存储库的例子，用于说明新选项大大减少了它们所需的存储空间，其中一个存储库占用的存储空间从 130049MB 减少到了 4432MB。

Git 存储库过大的后果不仅是占用过大的磁盘空间，而且还会导致 Git 运行缓慢，有时甚至会完全失败，这取决于延迟和可用带宽。

虽然新选项确实可以显著节省空间，但这些例子都是大型存储库，有很多潜在的文件名冲突。典型的 Git 存储库无法以同样的方式受益。尽管如此，开发者们还是很希望在 Git 的发行版本中看到这些新功能。

原文链接：

https://devclass.com/2024/10/29/microsoft-engineer-describes-a-flaw-in-git-that-can-hugely-bloat-repositories-fix-is-on-the-way/