Facebook为什么要弃用Git？

426 0 0

文章摘要

Greg Foster，Graphite.dev的联合创始人兼CTO，一直对Facebook为何放弃Git而选择Mercurial作为版本控制工具感到好奇。通过研究资料、观看技术讲座并与当时参与迁移的工程师交流，Foster找到了答案。本文将概述Foster的发现。

起初，Facebook使用Git作为其源代码控制系统，但随着代码库的增长，Git的性能问题逐渐显现。Facebook的代码库规模远超Linux内核，基本的Git命令执行时间超过45分钟，这促使Facebook寻求解决方案。尽管Git社区建议分割代码库，但这对Facebook并不可行。

在2012年，Facebook考虑了多种替代方案，包括闭源的Perforce和Bitkeeper，但最终选择了Mercurial。Mercurial的性能与Git相似，但架构更清晰，易于扩展。Facebook团队参加了Mercurial黑客松，发现了一个易于扩展的系统和积极欢迎改变的维护者社区。

迁移整个工程组织到Mercurial是一项艰巨的任务。Facebook团队花了几个月时间让工程师接受迁移的可能性，并努力映射Git和Mercurial之间的常见命令和工作流程。他们还收集了全公司使用Git命令的频率，以确保在Mercurial中也能执行最频繁的操作。通过充分的沟通和深思熟虑，Facebook成功说服了整个工程团队进行迁移。

Facebook为Mercurial做出了性能改进，使其成为大型单一代码库的最佳选择。Evan Priestley扩展了Phabricator以支持Mercurial。Facebook利用Mercurial的”diffs”概念创建了”堆叠”模式，解锁了新的代码审查并行化。前Facebook员工离开后，将他们的工作流程带到了新公司，形成了一个小而热情的堆叠diff爱好者社群。

这个故事的教训是，许多关键技术决策是由人而不是技术推动的。Facebook选择Mercurial并非因为其性能优于Git，而是因为维护者和代码库对合作的态度更开放。Facebook工程师与Mercurial维护者进行了面对面的交流，他们喜欢这种合作方式。在说服整个工程团队之前，这一决定是经过充分沟通和深思熟虑的。

善良和开放在开发工具的世界中非常重要。Foster希望在为源代码控制历史做出贡献时，能继续保持这种价值观。通过分享这些经验，我们可以更好地理解技术决策背后的动机，并从中汲取教训，以指导我们自己的技术选择。