1摘要
本文给大家剖析了一个有趣的现象:IT 业界使用最广泛的版本管理系统 Git,却不被硅谷领先的科技公司 google、Facebook 等垂青的原因。分析了 Google 的版本和分支管理模式、Git 的设计理念和存储结构,为企业 IT 的决策者提供一个版本管理系统技术选项的决策思路。
2背景
版本控制系统(VCS,Version Control System),或叫源码管理系统(SCM,Source Code Management)是几乎所有 IT 人员都熟悉和每天工作使用的工具。提到 VCS,你会想到哪个工具?估计大部分人都会想到 Git,尤其对于 85 后年轻一代 IT 人,甚至可能只知道 Git 这一种版本管理工具。
Git 是目前最流行的代码版本管理工具。它最初由 linux 之父 Linus Torvalds 开发出来,Linus 2007 年在某次演讲中提到他开发 Git 的几个准则:
•分布式:代码存储在多个机器、每个副本是平等的、支持离线工作
•高性能:每次 commit、branch、log、diff 等操作都非常快
•可靠:确保从 Git 签出(Checkout)的代码跟签入(Checkin)的代码完全一致除了 Git,业界流行的版本控制系统还有 Subversion、Mercurial 等。
3问题
Git 是一个非常适合开源社区的优秀的版本管理系统。但包括 Google 和 Facebooke 等多个硅谷巨头都没有采用,微软 windows 开发团队虽然用 Git,但用的是经过深度改造后的 Git。很奇怪,对不?
其实,Google 公司并非完全没有考虑过采用 Git,Linus 本人在 2007 年曾到 Google 公司进行过一次介绍 Git 的演讲,有兴趣的朋友可以参考:Linus 在 2007 年 Google Talk 上介绍 Git。当时 Google 采用一个商业软件 Perforce 作为代码版本管理工具,正为 Perforce 无法继续支持 Google 巨大代码仓库而寻觅替代方案。但最终 Google 选择了基于 Bigtable 自行研发版本管理工具 Piper,而没有采用 Linus 大神开发的、名满天下的 Git。
这到底是为什么呢?
4答案
Git 并不比 Subversion 更好,它只是不同
首先,让我们来看看 Git 是否(比其他流行的版本管理工具)更好,甚至最好。以 Git 市占率成为第 1 前最流行的 Subversion(简称 SVN)来对比。
在美版知乎网站 StackOverflow 上曾经有一个问题《Why is Git better than Subversion?》,被采纳的高赞回答是这样说的:
Git is not better than Subversion. But is also not worse. It's different.
是的,只是 different。有哪些不同呢?从 Git 官网的介绍和 Subversion 官网的介绍可以看出来:
上表是 Git 和 Subversion 官网强调的几个特性,我们来分析一下:
Git 非常适合开源社区
开源社区的核心诉求是开放、自由、共创,因此对版本管理系统的需求是:
依托 Linus 本人的超级影响力,加上 Git 本身非常适合开源协作的特性,Git 几乎成为开源社区唯一的代码版本管理系统。
5Git 并不特别适合企业
然而,Git 并不适合企业,尤其是企业中大型的软件系统。因为企业对源代码管理的诉求截然不同。源代码作为 IT 企业或企业的 IT 部门最核心的资产,管理需求是:
事实是: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 的分支和版本管理原则包括:
综上所述,Git 并不适合类似于 Google、Facebook 等采用单体代码仓库、主干开发模式的 IT 企业。因此,Google 于 2007 年自行开发了一套版本管理系统 Piper。可惜 Google 并没有开源出来。
最终结果:Google 在 2007 年前采用商业软件 Perforce 作为其源码管理系统;2007 年后自行研发 Piper 替代;Facebooke 则采用经过深度改造的 Mercurial 系统。
Google 和 Facebook 这 2 个硅谷巨头都没有采用最留下的 Git 来管理源码,根本原因在于其研发流程的核心:
7总结
代码版本管理系统的技术选项,对于整个 DevOps 流程的效率和质量有着重要的影响,而且一旦选定,往往迁移成本极大。作为企业 IT 部门的决策者,务必非常审慎的做决策。建议至少从以下维度评估:
8后记
上文中,我们提到 Google 分支和版本管理的 2 个原则:主干开发、大仓源码的主干依赖。这 2 点都跟国内业界大部分公司不同,读者可能会很疑虑。对于第 1 点,可以参考本公众号的文章《Google 工程效能三板斧之 单体代码仓库》。对于第 2 点,请期待后续分享。