在编程的世界里，Git 就像水一样常见，以至于我们认为它是创建和管理代码更改的唯一可行的工具。

前 Facebook 员工，2024 年

首先，我为什么关心？

我致力于构建 Graphite，它从根本上受到 Facebook 内部工具的启发。当我开始与朋友创建一家初创公司时，我从未听说过 Mercurial - 尽管我对开发工具的所有事物充满热情。我之前的工程经验包括个人项目、大学作业、Google 的 iOS 开发以及 Airbnb 的基础设施开发。在我的一生中，Git 就像水一样常见。事实上，它是如此常见，以至于我认为它是创建和管理代码更改的唯一可行的工具。

有趣的是，在 Airbnb，Mercurial 专家坐在离我几个座位远的地方，尽管我只知道他是一个好心的同桌，对他的贡献一无所知。Gregory Szorc

2021 年，我的队友托马斯和尼克打开了我的思路。他们来自 Facebook，令我惊讶的是，他们几乎不了解 Git。相反，他们接受了 Mercurial 模式和 Facebook 的“堆叠差异”工作流程的深入培训。随着时间的推移，他们向我推销了非 git 工具和模式的好处，最终我们做出了早期的公司转型，为 GitHub 开发人员带来了堆积的差异。在此过程中，我们制作了一个 CLI，将 Hg 的想法融入到 Git 中。

这篇文章与我们的初创公司无关。相反，这是过去三年来困扰我的根本问题。为什么 Facebook 用户（Metamates 🏴‍☠️）不使用 Git？

为什么要采用 Mercurial 并在其之上构建自定义工作流程？

我知道 Google 不使用 Git - 但这是有道理的 - Google 的工程比 Git 早五年多。另一方面，Facebook 是在 2004 年左右与 Git 创建的同时成立的，当 Facebook 认真评估源代码控制工具时，Git 比 Mercurial 更受欢迎。那么为什么 Facebook 不使用 Git 呢？

这个问题很小众，但我认为这是一个值得考虑的有趣问题。

如果 Facebook 在 2010 年代初就开始使用 Git 并做出贡献，工程世界可能会有所不同。Git 可能更加用户友好，并且可能本身支持堆叠更改。GitHub 可能为闭源软件开发提供了更好的支持。Uber 和 Pinterest 等前 Facebook 早期公司可能也使用 Git 和 GitHub 作为源代码控制，而不是 Phabricator 和 Mercurial，从而在过去十年中减少了生态系统的碎片化。

但 Facebook 并没有坚持使用 Git（作为他们的主要 monorepos）。相反，他们采用 Mercurial 进行版本控制，并在顶部逐渐添加自定义工具。为什么？首先，我尝试用谷歌搜索答案并找到以下明确的博客文章：

https://engineering.fb.com/2014/01/07/core-infra/scaling-mercurial-at-facebook/

这篇十年前的文章，以及后来的一些 YouTube 技术演讲，给了我一个起始答案：

“因为性能……”

但我想更深入地了解最初的决定工程师的意见。在队友的帮助下，我在 Facebook 前成员群组上发布了一个问题，询问这段历史。我还给参与该项目的两名原始工程师发送了冷电子邮件，要求他们迁移到 Mercurial - 他们很友善地取消了我的记录，并提供了该项目的个人帐户。以下是我了解到的 Facebook 不使用 Git 的完整原因 - 希望这篇文章可以帮助进一步记录 2024 年我们的工具为何如此的历史。

注：我从未在 Facebook 工作过，这个帐户是我作为一个没有在 Facebook 工作过的人对事实的最好理解。我能够与一些参与该项目的人交谈，并获得他们的许可来写下他们向我解释的内容。

Facebook 为何以及如何从 Git 迁移

根据 2014 年 Facebook 博客文章，Facebook 是从 Git 起步的。正如人们所预料的那样，这是他们当时对源代码控制系统的默认选择。但在 2012 年左右，他们开始达到规模极限。该帖子声称他们的代码库“甚至比 Linux 内核还要大很多倍，Linux 内核有 1700 万行代码和 44,000 个文件”。具体来说，工程师开始感觉 Git 操作很慢。虽然速度不算太慢，但足够慢到值得调查。

关键瓶颈是“统计”所有文件的过程。

Git 会检查每个文件，随着文件数量的增加，它自然会变得越来越慢。

工程师尝试运行模拟，创建一个虚拟存储库，以匹配 Facebook 几年后代码库的预期规模。结果令人震惊 - 基本的 Git 命令花了超过 45 分钟才能完成。用该项目的一位原始工程师的话来说，“这不是那种你想在所有工程师都抱怨之前就放弃的事情。到那时，这个东西就太笨重了。尝试进行损害控制，没关系，想出一个更清洁的解决方案，将是一项艰巨的努力。”

因此，一群乌合之众的瑞典人开始研究解决方案。首先，他们联系了 Git 维护者，看看如何扩展 Git 以更好地支持大型 monorepos：

以下是来自 Git 维护者的一封电子邮件的一些精选引述——已经过去 12 年了，但读到这些消息时我还是感到有些沮丧：

听起来好像你在一个 .git 中拥有所有内容。将大型存储库拆分为较小的 .git 存储库。

虽然您/可以/这样做，但这不是一个好主意，您应该拆分存储库

我同意。我在xx公司工作，该公司拥有多年的开发历史，拥有多个大型 CVS 存储库，我们正在缓慢但坚定地将代码库从 CVS 迁移到 Git。把事情分开。这将使您能够更好地重新组织事情，恕我直言，没有任何缺点。

虽然 Git 可以更好地处理大型存储库（特别是在交互式 rebase 中应用提交似乎会减慢较大存储库的速度），但对于统计 130 万个文件，您能做的只有这么多。

这种反应并不合作——而且在未来充满大型单一回购的情况下，这种反应也没有很好地适应。Git 维护者拒绝提高性能，而是建议 Facebook 对其 monorepo 进行分片。 然而，分片对于 Facebook 团队来说是不可能的，他们表示对 Git 不愿意扩展感到惊讶。传统上，大型科技公司提供免费的开源劳动力是一件很受欢迎的礼物，可以确保项目的长期寿命。

话虽这么说，Git 项目没有义务屈服于 Facebook 的要求——我无意将他们描绘成这个故事中的“坏人”。仅仅因为 Facebook 的要求而做某事并不是一种生活方式。有趣的是，两年后，Git 维护者在看到 Facebook 为 Mercurial 做出有意义的改进后似乎改变了语气：

他们邮寄了有关 git 性能问题的列表。据我所知，反馈相对较少。

我有这样的印象，如果他们有 git 开发社区相对不关心大型存储库的性能问题的印象，我不会感到惊讶。

所以问题是 git 社区是否有兴趣在如此大规模的场景中保持竞争力 - Mercurial 现在似乎是开箱即用的

十年后，Git 做出了重大改进，以更好地支持 monorepos。

今天的情况已经发生了很大的变化，Git 现在（知道如何做到这一点）在非常非常大的存储库上运行良好。

Ani Betts，前 Facebook 用户

考虑的替代方案

2012 年，Git 的替代品还很少。该团队考虑了闭源 Perforce，Google 以前的源代码控制解决方案。在与 Perforce 销售工程师的早期调查电话中，Facebook 指出了 Perforce 读取器和写入器节点之间的本地一致性的架构缺陷。这一回应并没有给人们带来信心——销售工程师没有意识到根本问题，也没有解决该问题的路线图计划。

还考虑了其他解决方案，例如 Bitkeeper，但很快就被取消了资格。最后一个选择是 Mercurial。它的性能与 Git 类似，但架构更简洁。Git 是一个由 Bash 和 C 代码组成的复杂网络，而 Mercurial 是使用面向对象的编码模式在 Python 中设计的，并且被设计为可扩展的。

其中一名调查工程师之前曾使用 Mercurial，因此该团队决定参加在阿姆斯特丹举行的 Mercurial 黑客马拉松以进一步调查。

由于我之前与 Mercurial 有过很多联系，因此在将 Mercurial 摆上桌面之前，我竭尽全力地寻求各种可能的替代方案。

布莱恩·奥沙利文，前 Facebook 员工

他们发现了一个易于扩展的系统和一个维护者社区，他们非常欢迎 Facebook 团队的积极改变。

我认为这就是提到的具体黑客马拉松，但我并不肯定。这段视频中展现了 2010 年初的真实氛围：

https://www.youtube.com/watch?v=fml4s6MEjW8

迁移整个工程组织

阿姆斯特丹黑客马拉松结束后，Facebook 团队被说服了。剩下的就是让公司的其他成员相信这次迁移。这是一项令人生畏的任务 - 工程师可能对工具更改极其敏感（想象一下 vim 与 emacs），并且更改源代码控制系统是一件大事。

团队尽可能顺利地出发，以免引发其他工程师的防御反应。接下来的事情听起来像是内部开发工具迁移的大师班。该团队花了几个月的时间宣传迁移到 Mercurial 的可能性，并花时间映射 Git 和 Mercurial 之间的所有常用命令和工作流程。他们甚至收集了整个公司运行的 Git 命令的频率，并专门记录了最频繁的操作在 Mercurial 中的工作方式。

其次，他们为开发人员创造了表达他们的担忧并讨论新系统中可能棘手的任何边缘情况的机会。团队一开始就认为他们会因为迟钝的 8 路章鱼合并假设而陷入激烈的争论。但令他们惊讶的是，他们发现同事工程师非常包容和友好。“没有人站起来并开始尖叫他们的特殊处境。”

最后，他们致力于迁移并将公司移交给 Mercurial。剩下的就是历史了。Facebook 为 Mercurial 做出了性能改进，使其成为大型单一存储库的最佳选择。 Evan Priestley 扩展了 Phabricator以支持 Mercurial。Facebook 利用 Mercurial 的“差异”概念创建了“堆叠”模式， 解锁了新颖的代码审查并行化。前 Facebook 员工跳槽到了新公司，并带来了他们的工作流程，创建了一个规模虽小但声名狼藉的 diff 爱好者崇拜者。最后，我遇到了其中一些爱好者，并决定用我 20 多岁的时间将 Mercurial 风格的堆叠差异引入 Git 和 GitHub。

结束语 这个故事的要点是什么？反思这些引述和采访，我想起了经典智慧：历史上许多关键技术决策都是人类驱动的，而不是技术驱动的。

善良和开放在开发工具的世界中走得很远，我的目标是在为源代码控制的历史做出贡献时继承这些价值观。

IT镜闻39

IT镜闻 · 目录

上一篇人工智能将意味着更多的程序员，而不是更少下一篇太忙”意味着你的个人策略很糟糕