我的书签
添加书签
移除书签3.2 版本管理系统的发展变迁
接着我们将按时间顺序来介绍具有代表性的版本管理系统。
版本管理系统是高效软件开发中必不可少的最基本的要素。因此在软件开发的历史上出现过很多版本管理系统的概念，这些概念也得到了实现。
这里让我们来简单回顾一下版本管理系统的历史，看一下与时俱进的版本管理系统的思考方式（图 3.1），同时也了解一下版本管理系统是如何发展到现在被认为是最有效率的分布式版本管理系统的。
※SCM 是 Source Code Management（代码管理系统）的简称。 本图参考了 “The version control timeline” by The plasticscm blog （http://codicesoftware.blogspot.com/2010/11/version-control-timeline.html ）。
图 3.1 版本管理系统的历史
3.2.1 没有版本管理系统的时代（20 世纪 70 年代以前）
20 世纪 60 年代 ～ 20 世纪 70 年代可以称为“版本管理系统的史前时代”。那时候笔者还没有出生。那个时代还没有可以称为版本管理系统的产品。
当时可能是以日期命名的目录来管理，或者制作表格文件来管理。有些开发团队也有可能在内部秘密地开发类似于版本管理系统的产品并独自使用。现在已经无从考证了。
3.2.2 RCS 的时代（20 世纪 80 年代）
现在某些 UNIX 操作系统上仍然捆绑安装的 RCS（Revision Control System）是于 1982 年发布的。它以管理本地机器上的文件为目的，是最早的真正意义上的版本管理系统。
RCS 具备了对文件之间的差异进行管理这种基本的版本管理机制，但还没有考虑到多人开发的情况，原因是要将管理的版本和多个人进行共享是非常困难的 12 。因此，这只是一款在本地机器上对文件进行管理的产品。
12 当然也并非完全不可能，通过共享目录，在 rcs 文件中粘贴符号链接，还是可以实现共享的。那时候一般所有的开发都在一台机器上进行。
3.2.3 CVS 的诞生（20 世纪 90 年代）
RCS 之后也发布过一些版本管理系统，但都是只能在本地机器上对文件进行管理，对多人开发的支持不够这一功能上的缺陷一直没有得到改善。
改变上述状况的是 1990 年左右发布的 CVS（Concurrent Versions System）。通过 CVS 名字中的 Concurrent（并行）就能知道，这是一款为了支持多人并行开发而设计的系统。
和 RCS 不同，CVS 采用了客户端 / 服务器的架构，通过 CVS 服务器使多人共享代码成为可能。从服务器签出代码进行编辑，然后再提交到服务器，这种现在看来理所应当的作业流程，可以说是由 CVS 最先确立的。CVS 还采用了合并模式来解决冲突，使得多人并行编辑同一文件变得容易进行。
但另一方面，版本管理仍采用基于文件的方式实现，每一个文件都有自己独立的版本号。因为没有变更集的概念，所以发生 bug 时要找出相关的一系列文件及其版本号是一件比较困难的事情。
虽然 CVS 实现了分支管理和标签管理，但创建分支是重量级的作业。特别是将分支再度合并回主干时的作业异常困难，根据项目的规模，有时不得不任命专门的人员来进行此作业。
CVS 是最早考虑到使用网络的版本管理系统，并且属于开源软件，使用是免费的，所以从 20 世纪 90 年代开始就被广泛使用。在一些开发现场，至今仍然在使用 CVS。
3.2.4 VSS、Perforce 等商用工具的诞生（20 世纪 90 年代）
在 CVS 被发布的几乎同一时期，各个软件企业也发布了多款商用的工具。具有代表性的是 PVCS、ClearCase、VSS 和 Perforce 等。
很多历史较久的开发团队至今还使用着上述版本管理系统。它们的后继产品如今多是将项目管理等功能整合起来，以 ALM（Application Lifecycle Management）工具的形式出售。
这些商用工具和 CVS 相同，也采用客户端 / 服务器模式。各个产品在实现的细节上有所差异，但大多都是以锁模式来消除冲突，并基于文件进行版本管理。
当然，这是 20 世纪 90 年代当时的情况，这些工具的最新版本改进并添加了各类功能，都有着易于使用的特性。
20 世纪 90 年代出现的这些商用工具各具特色，被市场广泛接受，但它们都没能解决分支管理和合并困难的问题。
3.2.5 Subversion 的诞生（2000 年以后）
进入 2000 年后，作为 CVS 的后继，Subversion 诞生了。它和 CVS 一样采用了客户端 / 服务器模式，通过合并模式来消除冲突。同时还引入了变更集的概念，使得赋予相关联的文件相同的版本号成为可能。据此，bug 的调查也变得容易不少。
并且 Subversion 还可以对 CVS 不支持的文件名和目录名的修改和删除操作进行追踪。对项目的管理也更为灵活，这也是 Subversion 的特色。
Subversion 可以说是现在最普及的版本管理系统。特别是它的 GUI 客户端工具 TortoiseSVN 非常完善，被 Windows 操作系统的用户广泛接受。
虽然分支的创建已经变得简单且快速，但是将分支合并回主干的作业依然非常费劲。因此多数开发现场都尽量避免使用合并，把分支的创建控制在最小限度。
3.2.6 分布式版本管理系统的诞生（2005 年以后）
上面介绍的 CVS、Subversion 以及各个商用的工具都是基于客户端 / 服务器模式来实现的。代码库只存在于服务器上，各开发人员从服务器上下载代码，编辑后再提交到服务器。
2005 年出现的 Git 改变了上述方式。
Git 的开发者是著名的 Linux 之父 Linus Torvalds。Linux 社区原本使用的是专有 13 的分布式版本管理系统（Distributed Version Control System，DVCS）BitKeeper14 ，但后来因为某些原因不得不放弃使用 BitKeeper，于是就开始了 Git15 的开发。
13 由特定的软件生产商发布的规格等不公开的产品。
15 放弃 BitKeeper 的原因比较复杂，其中涉及了商业协议等。有兴趣的读者可以参考 http://www.path8.net/tn/archives/6039 。——译者注
Git 出现之后，开源项目业界使用分布式版本管理系统的项目逐渐增加，分布式版本管理系统逐渐扎根下来。如今已经普及到了开源项目以外的一般项目中。分布式版本管理系统中除了最有名的 Git 之外，其他还有 Mercurial16 、Bazaar17 等。
16 http://mercurial.selenic.com/
17 http://bazaar.canonical.com/
分布式版本管理系统最显著的特征就是没有中央代码库，完全采用 peer to peer 的模式。开发人员并不是从中央代码库中下载代码，而是将代码库完整地克隆到本地机器上，使得本地机器上保存有完整的代码库备份 18 。据此，不需要借助网络就能够完成所有的操作，因此具有提交等命令执行速度快的特征。因为向本地代码库提交的速度很快，所以可以频繁地进行提交，以降低工作成果丢失的风险。
18 虽说机制上不需要中央代码库，但实际使用中往往还是会设立中央代码库。
分支也是一样，由于只需自己本地的代码库就能创建分支，因此在想进行某种尝试时，就可以随意地创建分支。这和 Subversion 之前的只能在中央服务器上创建分支的中央集权型版本管理系统有很大的区别。
当然，Subversion 之前的产品中已经实现的变更集的管理和合并模式的冲突消解等功能，Git 都继承了下来。
总之，提交、分支、合并的低开销，只要正确提交就几乎不会丢失作业，试验性质的分支创建方便，能够实现灵活的工作流程，这些都是 Git 比较主要的特征。分布式版本管理系统的出现，可以说是版本管理系统和团队开发的重大进步。
但是难点在于学习成本。由于分布式版本管理系统（在系统上）没有中央代码库的概念，和之前的版本管理系统的思想方式有着根本性的差异，因此初次使用的人基本都会感到不知所措。
但分布式版本管理系统是值得花费这样的成本的。世界上几乎所有的开源项目都采用了分布式版本管理系统，从这点就能看出。
3.2.7 番外篇 ：GitHub 的诞生
虽然有些偏离版本管理系统的历史，但这里我们还是要提下 GitHub。
GitHub 是 2008 年诞生的 Git 项目的在线托管服务。“社交编程”这个标语可能更为出名 19 。
19 到 2014 年，GitHub 网站上社交编程这个标语已经没有了。
GitHub 之前也有代码托管服务，如 SourceForge20 和 assembla 21 等。这些服务的特点是能够方便地托管代码，还支持多人开发和缺陷管理，因此主要在开源软件界被广泛使用。
GitHub 是上述服务的 Git 版，和上述托管服务相比，GitHub 更为流行和普及。
GitHub 流行起来的原因有很多，其中最主要的是得益于 Fork 和 Pull Request 这两个特色功能。如果别人的项目中有你感兴趣的地方，可以方便地克隆该项目（Fork）并添加修改，再发送补丁申请将自己的修改反映到原来的项目中（Pull Request）。
之前的中央集权型版本管理系统是无法实现上述功能的。首先是无法对已有项目进行克隆。另外，发送给项目的补丁（修改）如果不能立即反映到项目中，也得不到保存，最终就会丢失。
GitHub 的成功之处可以说在于将分布式管理系统（Git）“不存在中央代码库”这一特征所具有的潜能最大限度地激发了出来。原本以 Git 为代表的分布式版本管理系统有着运行速度快、创建分支简单快捷、合并方便等特点，但同时也存在 API 比较复杂，不了熟悉的话很难灵活应用这样的问题。
GitHub 可以说是通过易用易懂的 UI 和高超的设计灵感将 Git 的潜力充分激发了出来，一下子改变了开发人员的世界。
如今参加开源项目的门坎已经大大降低。如果开源代码中有什么看不惯的地方，或者发现了 bug，都可以 Fork 并进行修改。
修改顺利的话，可以向原来的项目进行 Pull Request，将修改反映到项目中。这样就对开源项目做出了自己的贡献，不需要其他任何杂七杂八的事情。
如此便捷的 GitHub，如果只用在开源软件界就太浪费了。事实上，世界上的很多公司都已经在使用 GitHub 开发自己的产品。可以毫不夸张地说日本国内主要的互联网服务提供商几乎都在使用 GitHub。
笔者现在所属的公司也在使用 GitHub。一旦了解了 GitHub 的便利性和分布式版本管理系统的自由性，就很难再回到之前的中央集权型版本管理系统了。听说一些资深的工程师，换工作时都会确认对方企业是否使用 GitHub。
GitHub 的共享代码库是免费的，但私有的代码库还是收费的，这点请注意。并且 GitHub 还有供公司内部局域网使用的产品 GitHub Enterprise22 。企业在开发产品时使用私有代码库的花费 23 或者 GitHub Enterprise 的花费需要预先纳入到项目预算中。但这样的花费还算是物 有所值的。24 25 26
22 https://enterprise.github.com/
24 根据代码库和用户数量的不同，有各种价格的套餐。具体请参考 GitHub 的网站。
25 也有和 GitHub 功能几乎完全相同，并且私有代码库在一定程度上也可以免费使用的服务，那就是 Bitbucket（https://bitbucket.org ）。Bitbucket 原本是 Mercurial 这款分布式版本管理系统的托管服务，现在也支持 Git 了。在公司内部导入 GitHub 之前，可以先使用 Bitbucket 的私有代码库，让开发人员先体验一下分布式版本管理系统和 Pull Request，之后再正式地导入 GitHub。或者就这样继续使用 Bitbucket 也是一个不坏的选择。
26 在某些情况下，可能会由于安全策略的问题而不允许使用 GitHub 这样的外部服务，或者没有使用 GitHub Enterprise 的预算。这时可以选择使用 Gitlab（http://gitlab.org ）、GitBucket（https://github.com/takezoe/gitbucket ）等 GitHub 的克隆。
3.2.8 版本管理系统的导入情况
走马观花地看了一遍版本管理系统的历史。从没有版本管理系统到 RCS 的出现，CVS、Subversion 的出现，再到分布式版本管理系统的 Git 的出现，仅仅用了 20 年的时间。在这期间，版本管理系统从基于文件到基于变更集、从锁模式到合并模式、从中央集权型版本管理系统到分布式版本管理系统，有了巨大的进步。这些进步可以说都是人们为了使多人同时并行开发更容易，以及提高开发速度而努力的结果。
取得这样的进步只用了 20 年的时间，可以说是相当迅速了。当时刚刚开始工作的 20 岁左右的工程师，如今已 40 岁左右，并成为了开发现场的中坚力量。到了 40 多岁这个年纪，很多工程师都已经成为项目经理，或者对工具和技术的选择拥有决定权。当然也有人依然在开发现场编写代码。
特别是在日本，技术方面的信息传入比起美国要晚一些。20 世纪 90 年代初出现的 CVS 好像到 90 年代后期才开始被广泛使用，2000 年出现的 Subversion 到 2004 ～ 2005 年才逐渐普及。至于 2005 年出现的 Git，到 2010 年才有一部分先进的公司开始使用。直到 2014 年，多数互联网公司才开始讨论采用 Git。这些都是事实。
如今还在使用 20 世纪 90 年代发布的商用版本管理系统的公司多数是企业级的系统集成商（SIer）。特别是日本企业，它们有着只要系统尚可使用就不会强行升级这样独特的文化，状况就可想而知了。
你所在的公司在使用 Git 或者 GitHub 吗？如果是的话那么你是幸运的。你所在的是非常理解技术的优秀的公司，或者是最近成立的创新公司。请珍惜这样的环境。
如此幸运的人应该不会太多。比如有些开发现场的项目经理当年在一线工作时只能采用 CVS 这样基于文件的版本管理，或者用惯了 VSS 这样基于锁的难以并行开发的系统，这样的开发现场往往不会使用 Git 或 GitHub。另外，由于企业文化保守，至今仍在使用 VSS 的企业，以及只是形式上导入了 Subversion，用法和 VSS 的时候基本没有区别的企业也是比较多见的。
再重复一下，版本管理系统只有短短 20 年的历史 27 。
27 不只是版本管理系统，本书中出现的工具和插件都在这不到 20 年的时间内有了巨大的进步。
假如你的上司、你所在的公司对于版本管理的理解不足，还在使用旧的模式进行管理，这是对技术方面的懈怠而造成的结果。在认识到这一点的基础上，请从自己开始努力，来改变这样的公司文化。
