2024 年了，Facebook、Google 竟然都不用 Git 管理代码？

关注

转载最新推荐文章于 2026-10-25 19:11:49 发布 8.2k 阅读 AI 写同款· GEO 优化 ›

多分支合并最佳实践：从Git操作到协作流程设计多分支合并是软件工程中版本控制与团队协作交汇的核心环节，其本质并非单纯的技术命令（如merge或rebase）执行，而是代码演进节奏、责任归属与知识同步的显性化表达。理解Git分支模型的原理，掌握merge与rebase在协作语境下的语义差异，能显著降低冲突熵增、提升交付确定性。技术价值体现在保障主干可发布性、支持灰度与回滚能力、强化CI/CD流水线稳定性；典型应用场景包括电商迭代、金融系统热修复、SaaS产品多租户功能并行开发等。本文聚焦真实项目中的分支生命周期管理、冲突分类决策与可逆性设计，提供可落地的阅读详情

根据最新的调查数据，高达 93.87% 的开发者选择使用 Git 作为他们的代码版本控制系统。然而，令人惊讶的是，在2024年依然有少数知名公司并未采用 Git。据悉，Facebook 选择的是 Mercurial，而 Google 则青睐于Piper。那么，这些行业巨头为何选择不随大流，转而采用其他版本管理系统呢？这些系统又各自具备哪些独特之处呢？接下来，本文将深入探讨这些问题。

Git 是一个分布式版本控制系统，用于跟踪代码的变化并协调多个开发人员在同一项目上的工作。Git 是由 Linus Torvalds 为了管理 Linux 内核开发而创建的，如今已经成为开源项目中最流行的版本控制系统，没有之一。

Mercurial

是什么？

Facebook最初选择了Git，但在代码规模急剧增长后，他们开始遭遇Git性能方面的限制。特别是在执行类似"stat"的操作时，随着文件数量的增加，Git的性能开始变慢。尽管团队尝试联系Git项目的维护者以改进这些问题，但最终他们决定不再依赖Git，并转而选择了Mercurial，因为Mercurial的架构更加干净，且在面对大型monorepo时性能较好。Facebook也曾考虑过其他备选方案，比如闭源的Perforce和Bitkeeper，但最终选择了Mercurial，因为其性能与Git相当，而且有清晰的架构，易于扩展。

Mercurial 是一个分布式版本控制系统，用于跟踪项目的变化和管理文件的历史记录。它允许开发人员协作，跟踪代码更改，并管理源代码库的版本。Mercurial 提供了一种灵活的工作流程，能够适应不同团队和项目的需求。

Mercurial 具有以下特点和优势：

性能：Mercurial能够良好地支持大型单一代码库，拥有较好的性能表现，特别适合于大规模项目。
易于扩展：Mercurial系统易于扩展，同时其设计相对清晰，采用了面向对象编程模式，由Python编写。
与维护者合作：Facebook团队与Mercurial的维护者进行了面对面的交流，喜欢这个合作伙伴的理念，而且维护者社区对Facebook团队的大胆改变给予了积极的欢迎。

为什么？

Facebook选择Mercurial而不是Git的原因主要包括：

性能问题：在使用Git时，Facebook遇到了扩展性上的限制，尤其是对于大型单库的操作效率。
合作与支持：Mercurial 维护者和代码库更愿意与其合作，Facebook的工程师们得到了维护者和社区的支持。
社交化迁移过程：Facebook 团队花了数月时间社交化地进行迁移到Mercurial的可能性，并且经过全公司的调查和讨论，使整个迁移过程更为顺利。

总之，Facebook 选择 Mercurial 并非仅仅因为它比Git性能更好，而更多地是因为 Mercurial 的维护者和代码库更加愿意与Facebook合作，并且在工程团队中得到了有效的传播和沟通。

Piper

谷歌公司内部主要使用的是自行研发的版本管理工具 Piper 来管理代码，而不是Git。谷歌的 90% 以上的代码都存放在Piper中。对于那些开源的、需要外部协作的项目，如 Android 项目和 Chrome 项目，谷歌会选择使用 Git。

是什么？

Piper 与其他版本管理系统不同，它只有一个代码仓库。也就是说，Google 将所有代码都放在了一个代码仓库，整个公司使用不同语言编写的超过10亿文件，近百 TB 源代码都存放在自行开发的版本管理系统 Piper 中，只当项目开源且需要外部协作时，才会使用业界流行的 Git。

Piper 整个仓库采用树状结构，每个团队有自己的目录，目录路径就是代码的命名空间。每个目录都有负责人，负责批准该目录的文件变动。在权限控制方面，Piper支持文件级别的权限控制，大部分代码对所有用户可见，但重要的配置文件和机密的关键业务设有访问限制。

在工作流方面，开发者先创建文件的本地拷贝，这叫做“工作区”。完成开发后，工作区的快照会共享给其他开发者进行代码评审。只有通过评审的代码才能合并到中央仓库。谷歌采用“主干开发”的方式，代码一般提交到主干的头部，避免了合并分支时的麻烦。所有代码在合并进仓库之前，都必须进行代码评审，大部分评审对所有人开放，任何谷歌员工都可以对代码提意见或者提交变动。

为什么？

那为什么 Google 使用 Piper，而不是使用 Git 呢？

规模：Google 的代码库包含约十亿个文件，3500 万次提交记录，这远远超出了一般代码库的规模。Piper 被设计用来处理这种大规模的代码库，以及数以万计的开发者对单一代码库的共享，这使得它更适合于谷歌的特殊需求。
安全性：Piper 被设计时考虑了安全功能，包括支持文件级别的访问控制列表，对文件读写访问进行日志记录等。这些功能对于谷歌来说是非常重要的，因为他们的源代码是公司最重要的资产之一。这种强调安全性和权限控制的设计使得 Piper 更适合谷歌的需要。
操作和扩展性：Piper 的工作流程被设计成能够满足 Google 这样规模的组织的需求。Piper 提供了一种基于主干的开发模式，这使得大多数开发人员可以在“头部”进行开发，也就是主干代码的最新版本。此外，Piper 还具有基于云的存储后端和支持工作区快照的系统，这些特性都使得它更适合谷歌这样规模庞大的组织。

SVN

说完了 Facebook 和 Google 使用的版本控制系统，最后再来简单了解一下使用率排在第二的版本控制系统——SVN。

SVN，全称 Subversion，是一个开放源代码的版本控制系统。它主要用于管理和跟踪文件和目录的变化，允许多个人在同一个项目上同时工作，并且可以追踪每个人的修改，以便在需要时进行版本回退或合并。

SVN的工作原理是将项目文件和版本历史存储在中央资料档案库中，这个档案库可以记录每一次文件的变动，因此用户可以把档案恢复到旧的版本或浏览文件的变动历史。SVN通过高效的分支管理系统实现多个人共同开发同一个项目，实现共享资源，并最终实现集中式的管理。

Git 的使用率比 SVN 多的原因主要有以下几点：

分布式特性：Git是分布式的版本控制系统，每个开发者本地都拥有完整的代码库，可以独立地进行代码提交、分支创建等操作，无需依赖于中央服务器。而SVN则是集中式的版本控制系统，所有的版本信息都存储在中央服务器上，开发者需要通过中央服务器进行代码的提交和更新。因此，Git更适用于网络不稳定或团队协作地域分布广泛的场景。
性能优势：由于Git的操作大多在本地进行，因此其性能通常比SVN快，特别是在大型项目或网络状况不佳的情况下。SVN在处理大型存储库和大文件时可能会遇到性能瓶颈。
灵活性和分支策略：Git支持多种分支策略，可以根据项目需求选择合适的策略，使得团队协作更加灵活。相比之下，SVN在分支支持方面相对较弱，分支管理较为复杂。
社区支持和生态发展：Git在开源社区中得到了广泛的支持和应用，拥有庞大的用户群体和丰富的生态资源。这使得Git在功能更新、问题解决等方面更具优势。

通常情况下，SVN 在以下情况下更适用：

集中式管理需求：当团队更习惯于集中式的版本控制系统时，SVN 可能更为适合，因为它对于权限控制和集中式管理提供了更直接的支持。
简单操作：对于那些不需要复杂分支和合并操作的项目，SVN 提供了更为直观的界面和操作方式。
二进制文件处理：在处理大型二进制文件时，SVN 通常比 Git 更加高效，因为 SVN 对二进制文件的处理较为友好。
稳定性需求：在一些企业环境中，特别是传统的软件开发公司，他们可能更倾向于使用 SVN，因为它有着更长时间的发展历史和更成熟的稳定性。

总结

Facebook选择Mercurial的原因主要是出于性能考量和合作与支持的考虑。随着代码规模的急剧增长，Facebook发现Git在大型单库操作上的性能存在限制。与此同时，Mercurial的维护者和社区更愿意与Facebook合作，提供了良好的支持和沟通渠道。这使得Facebook工程师们得到了必要的支持，并顺利完成了从Git到Mercurial的迁移。

而Google选择自行研发的Piper系统则是基于其特殊的代码库规模和安全性需求。Google的代码库规模庞大，包含数亿个文件和大量提交记录，这要求版本管理系统具备处理大规模代码库的能力。此外，Google还非常注重源代码的安全性，因此Piper系统在设计时考虑了安全功能，如文件级别的访问控制和日志记录等。