Google 和 Facebook 为什么不用 Git 管理源码？( 二 ) _Git

易用性：简单的代码签出（Check-out）、嵌入（Check-in）、分支、合并等操作；

多种类的资源版本管理，包括源代码，也包括资源文件（图片、音乐、视频、设计文件等）；

规模：支持数百 GB 甚至 TB 级规模的代码仓库，设想一个数千人的开发团队超过 10 年代码积累的大型软件，这个规模的代码仓库是完全可能的。而这，恰恰就是 Google 为例的大型 IT 公司所需求的。Linus 2007 年在 Google 的演讲中，2 名 Google 员工提出了 2 个问题：

如果你有一个超级超级大的代码库（repository），想用 Git 来管理，还不能让业务中断 6 个月，你怎么做？

使用 Git 怎么只 pull 代码库的其中一部分 path？Linus 大神没有正面回答这 2 个问题。

事实是：Git 做不到。
Git 之所以无法存储巨大的代码库，也无法 clone、pull、push 代码库文件树的某个分支，是由其存储结构和设计理念所制约的，并不是简单增加一个特性就可以解决的。这也是为什么 Google 员工 2007 年就向 Linus 提出这 2 个问题，但到今天为止，Git 仍然不能支持的根本原因。（后来版本的 Git 支持通过 filter 和 sparce checkout 只克隆 / 拉取某些目录的代码，但性能非常低）。
在 Git 对象模型里，所有对象都以 SHA-1 id 表述，包括 4 类对象：
1.blob：用于存储文件数据；
2.tree：可以理解为目录，它指向其他目录或 blob；
3.commit：一棵代码树的提交点；
4.tag：标记特别的提交（commit），通常用于标记某次发布；
其中，tag 和 branch 只是指向 commit 的一个指针。Git 的核心存储在于前 3 者。其结构如下图：

文章插图

更详细的 Git 存储和访问机制，超出本文的范畴，关注本公众号，我将在未来分享。
6源码管理系统的选型取决于研发流程
除了上面所述的考虑因素，源码管理系统的选型最重要的还是取决于研发流程，尤其是分支和版本关联
Google 的分支和版本管理原则包括：

基于充分测试的主干开发：这意味着并不需要太多分支、代码集中式存储；
基于大仓源码的主干依赖：就是把所有的模块和子工程都放在同一个代码仓库中，代码间以源码的主干版本为依赖，所以代码仓库会非常巨大。这 2 点，都是 Git 无法满足的。

综上所述，Git 并不适合类似于 Google、Facebook 等采用单体代码仓库、主干开发模式的 IT 企业。因此，Google 于 2007 年自行开发了一套版本管理系统 Piper 。可惜 Google 并没有开源出来。
最终结果：Google 在 2007 年前采用商业软件 Perforce 作为其源码管理系统；2007 年后自行研发 Piper 替代；Facebooke 则采用经过深度改造的 Mercurial 系统。
Google 和 Facebook 这 2 个硅谷巨头都没有采用最留下的 Git 来管理源码，根本原因在于其研发流程的核心：

主干开发；
基于大仓源码的主干依赖；

7总结
代码版本管理系统的技术选项，对于整个 DevOps 流程的效率和质量有着重要的影响，而且一旦选定，往往迁移成本极大。作为企业 IT 部门的决策者，务必非常审慎的做决策。建议至少从以下维度评估：

研发流程是主干开发，还是分支开发；
代码模块之间（包括对公司内部和第三方）的依赖，以制品（编译后的 jar、so 等二进制或字节码包）还是源代码形式；
版本发布模式：主干发布、还是分支发布；
代码的开放程度：是企业全部开放，还是需要局部开发；
代码的安全要求；经过多维度的评估，能让企业 IT 的决策者作出更准确的决策。

8后记
上文中，我们提到 Google 分支和版本管理的 2 个原则：主干开发、大仓源码的主干依赖。这 2 点都跟国内业界大部分公司不同，读者可能会很疑虑。对于第 1 点，可以参考本公众号的文章《Google 工程效能三板斧之单体代码仓库》。对于第 2 点，请期待后续分享。

【Google 和 Facebook 为什么不用 Git 管理源码？】