Dropbox 工程师通过解决 Git 存储和增量压缩模型的低效问题，将后端单体库的大小从 87GB 缩减至 20GB，从而提升了开发人员的工作效率和持续集成性能。该存储库是 Dropbox 各团队后端服务和共享库的中央集成点。这一举措的实施源于该存储库在扩展方面面临的挑战。
随着单体库（monorepo）规模的不断扩大，工程团队开始遇到克隆操作缓慢的问题，有时甚至需要超过一个小时才能完成；此外，由于反复获取和构建带来的开销，持续集成（CI）管道的性能也随之下降。规模的扩大还增加了触及存储库托管限制的风险。根据 Dropbox 工程团队的调查结果，该问题的主要原因不是大型二进制文件或意外提交，而是 Git 内部的压缩算法在处理大量相关文件集时的处理方式。
Git 会识别文件间的相似性并高效地存储差异，利用增量压缩来节省存储空间。在规模化应用中，Dropbox 工程师们发现，由这些启发式算法所生成的打包文件并不理想，存储库的增长规模与实际代码变更相比显得不成比例。预期增长与实际增长之间的偏差促使他们对存储行为进行了更深入的调查，而不仅仅是关注存储库内容本身。
正如 Dropbox 高级软件工程师 Ishan Mishra 所指出的那样：
这种增长速度与我们预期的正常开发活动不符，即便是以 Dropbox 的规模来看也是如此。这表明问题不仅在于我们存储了什么，还在于存储的方式。
该团队将存储库视为生产基础设施，并对存储模式进行了详细分析。他们实施了优化的打包策略，并调整了 Git 构建对象增量的方式，重点优化增量窗口和深度行为。由于在进行克隆和获取操作时，服务器端打包由 GitHub 基础设施管理，Dropbox 工程师与 GitHub 团队合作对这些参数进行了调优。为了降低运营风险，在正式部署前，这些更改已经在镜像环境中做过验证。
在 LinkedIn 上的一篇博文中， Shailesh Mishra 指出：“这是工具层面的假设与大规模代码库结构之间的冲突。”
经过这些优化，存储库大小从 87GB 缩减到了 20GB，降幅约为 77%。克隆时间从一个多小时缩短至 15 分钟以内。而且，由于数据传输和处理开销减少，持续集成（CI）管道的执行速度也得到了提升。这些改进还降低了触及存储库大小限制的可能性，并缩短了开发人员的入职时间。
Dropbox Git 数据大小缩减（图片来源：Dropbox 博文）
Dropbox 工程师们强调，此次项目的主要经验在于：必须将版本控制系统视为关键基础设施，因为其存储行为会直接影响工程开发速度。该项目结合了工具层面的优化、与 GitHub 的跨组织协作以及分阶段验证，为的是在不干扰开发人员工作流的前提下确保部署安全。
声明：本文为 InfoQ 翻译，未经许可禁止转载。
原文链接：https://www.infoq.com/news/2026/04/dropbox-reduces-git-optimization/