3.3　分布式版本管理系统

3.3.1　使用分布式版本管理系统的 5 大原因

2014 年最先进的版本管理系统——分布式版本管理系统的优点有以下 5 个。

●…… 能将代码库完整地复制到本地

这是和中央集权型版本管理系统的主要差异。之后列举的优点几乎都是基于这个特点的。

●…… 运行速度快

本地机器上存放有所有的文件，因此通信开销低，提交、分支、合并等操作速度快，这是分布式版本管理系统的一大优势。

●…… 临时作业的提交易于管理

和中央集权型版本管理系统不同，分布式版本管理系统可以在不影响全体代码库的情况下在本地提交代码。这样可以方便地保存临时作业，有助提高开发效率。

另一个优点是可以不用考虑对整体的影响，方便地进行实验性质的开发。

●…… 分支、合并简单方便

相同的内容已经提到过很多次了，分支创建简单、快速，不仅能提高开发速度，也不会阻碍你的各种尝试，这也是一大优点。

●…… 可以不受地点的限制进行协作开发

借助本地环境中保存有全部文件这一特性，无论在无法连接互联网的离线环境，例如在乘坐飞机时，还是访问互联网比较困难的偏远地区，都能够顺利地进行开发。可以说最适合不限地区和国家的开源代码项目了。并且该特性最近还起到了将软件开发企业从地域限制中解放出来的作用，以美国西海岸的企业为中心，开发人员的多国籍化、多地区化正在推进之中。

3.3.2　分布式版本管理系统的缺点

分布式版本管理系统作为当前最先进的版本管理系统，基本上是优点占大部分。但缺点或者说需要注意的地方也并不是没有。

●…… 系统中没有真正意义上的最新版本

因为系统中没有中央数据库，所以也不存在最新版本这一概念。Subversion 的话，最新版本自然就是 trunk 上的 HEAD。而分布式版本管理系统的情况下，如果没有在运用策略上确定中央数据库，那么最新版本也就无从谈起。

●…… 没有真正意义上的版本号

没有中央代码库就意味着不知道哪个是最新版本，或者说哪个都有可能是最新版本。也就是说，即使像 Subversion 那样连续地分配版本号 1、2、3 也没有任何意义。例如版本号 231，至于代码库 A 的 231 版本和代码库 A' 的 231 版本哪个是新版本，就完全不知道了。

因此，分布式版管理系统为每一个变更集分配了 GUID28 （Globally Unique IDentifier）。也就是说，并不是管理版本的新旧，而是管理变更集的唯一性。这样的管理方法与合并的便利性之间有着密切的关联，但开发人员之间的对话就比较麻烦了。这是因为必须用隐晦的 GUID 来称呼修改。比如“231 版本”，就不得不改称为“‘26fde9ed06bc4d0f8773cb399e73eb63’的修改”，如果没有习惯的话，还真是让人吃不消。

28 是指全局唯一标识符。原本是不重复的 128 位的整数，考虑到可读性方面的问题，分布式版本管理系统在使用时采用了“26fde9ed06bc4d0f8773cb399e73eb63”这样的 32 位十六进制的表现形式。

●…… 工作流程的配置过于灵活，容易产生混乱

分布式版本管理系统中不存在中央代码库，任何一个代码库都是等价、平行的。系统上可以从任意一个代码库向另一个代码库自由地通过 Push/Pull 来发送修改补丁。这样的形式能够灵活地组建工作流程，可以算得上是优点。但如果团队成员没有习惯的话，反而容易产生混乱。

因此，实际运用中会设立中央代码库，各开发人员从中央代码库克隆代码进行开发，这是比较常规的做法。如此一来，实际运用中使用 GitHub 就成了最方便的选择，这样做的开发团队也比较多见。

●…… 思维方式的习惯需要一定的时间

如上所述，分布式版本管理系统的缺点的根本原因在于：在使用分布式版本管理系统时需要在至今为止的中央集权型版本管理系统的基础上进行范式转变 29 。

29 即思维方式的根本转变。——译者注

分布式版本管理系统和 CVS、Subversion、VSS、Perforce 的构造都不类似，所以越是习惯以前的版本管理系统的人，在一开始时就越是容易感到困惑，操作也容易失败。这也是导入分布式版本管理系统最大的壁垒，好在现在已经出现了较多的入门书籍可供参考。