【外评】为什么 Facebook 不使用 Git
内容提要
这篇文章讨论了Facebook为什么选择使用Mercurial而不是Git。Facebook在2012年遇到了Git扩展限制，导致操作缓慢。他们考虑了Perforce和Bitkeeper等替代方案，最终选择了Mercurial。文章还提到了Facebook对Mercurial进行了改进，并将其用于大型单体。作者认为技术决策往往是由人驱动而不是由技术驱动的。
延伸解读
性能瓶颈的具体表现
文章指出，Facebook 在 2012 年左右遇到 Git 扩展限制，核心瓶颈在于 Git 需要对所有文件进行 stat 操作。随着代码库文件数量增长，这一过程变得极其缓慢。工程师模拟未来规模时发现，基本 Git 命令需要 45 分钟以上才能完成。这种性能退化并非突然崩溃，而是逐渐累积，促使团队在问题恶化前主动寻求替代方案。
Git 维护者的态度与分片建议
面对 Facebook 的扩展需求，Git 维护者建议将大型 monorepo 拆分成多个较小仓库，而非改进 Git 本身对超大仓库的支持。文章引用了维护者邮件，其中明确表示拆分是更好做法，并认为对 130 万个文件的 stat 操作难以优化。Facebook 认为分片不可行，对 Git 社区不愿扩展的态度感到惊讶。这一分歧成为迁移决策的重要推动因素。
Mercurial 的架构优势与社区合作
文章对比了 Mercurial 与 Git 的架构：Git 由 Bash 和 C 代码组成，较为复杂；Mercurial 用 Python 设计，采用面向对象模式，更简洁且易于扩展。Facebook 团队通过阿姆斯特丹黑客马拉松深入接触 Mercurial 社区，发现维护者非常欢迎合作。这种开放态度与 Git 维护者的保守形成对比，最终促使 Facebook 选择 Mercurial 并为其贡献性能改进。
迁移中的人为因素与沟通策略
迁移整个工程组织时，Facebook 团队没有强行推进，而是花了几个月沟通，绘制 Git 与 Mercurial 常用命令和工作流程图，统计公司内 Git 命令运行频率，并记录最频繁操作在 Mercurial 中的对应方式。他们还为开发者创造机会表达担忧，讨论边缘情况。结果出乎意料：工程师们包容友好，没有出现激烈反对。这表明技术迁移的成功往往取决于对人的关注和充分准备。
Q&A
Facebook为什么选择Mercurial而不是Git？
Facebook选择Mercurial是因为在2012年遇到Git的扩展限制，导致操作缓慢，而Mercurial的架构更简洁，易于扩展，适合他们的需求。
Facebook在迁移到Mercurial的过程中采取了哪些步骤？
Facebook团队进行了充分的沟通，绘制了Git和Mercurial之间的命令和工作流程图，并统计了Git命令的使用频率，以便顺利迁移。
Facebook在使用Git时遇到了什么性能问题？
Facebook在使用Git时，随着代码库的扩大，操作变得缓慢，特别是在对所有文件进行统计时，基本命令需要45分钟以上才能完成。
Facebook考虑过哪些替代方案来替换Git？
Facebook考虑过Perforce和Bitkeeper等替代方案，但最终选择了Mercurial，因为其性能与Git相似且架构更简洁。
Facebook对Mercurial做了哪些改进？
Facebook对Mercurial进行了性能改进，并利用其“diffs”概念创建了一种“堆栈”模式，实现了新颖的代码审查并行化。
技术决策在Facebook是如何受到人驱动的？
Facebook的技术决策往往是由人驱动的，工程师们与Mercurial维护者的合作和沟通促进了Mercurial的采用，而不是单纯依赖技术的优劣。
