要实施GJB5000A的配置管理过程，需要有配置管理工具作支撑。实际上，配置管理工具至少有中央版本控制系统、 基于流的版本控制系统和分布式版本控制系统等三种。
- 中央版本控制系统
中央版本控制系统是发展比较早，使用也比较广的一种版本控制系统，著名的CVS和SVN都属于这种。中央版本控制系统支持多个开发人员同时在同一个代码库上工作，使用客户端/服务器模式的架构，支持分支合并和打标签方法。SVN还允许在本地创建工作区(代码副本)。
使用中央版本控制系统一般流程如下：
- 从中央代码库获取最新版本的代码到本地；
- 在本地编写/修改代码；
- 将本地修改与中央代码库中的任何新更新进行合并，并修复冲突；
- (如果实施持续集成)在本地运行并提交构建；
- 提交修改(包括合并的代码)到版本控制系统中。
- 基于流的版本控制系统
基于流的版本控制系统的特点是可以把一系列修改一次性应用到多个分支上，从而减少合并时的麻烦。著名的ClearCase属于这种。
在基于流的版本控制系统中，流之间是可以相互继承的。这就是它可以“把一系列修改一次性应用到多个分支上”的原因。因为，当你把某次修改应用到一个指定的流上，它的所有子孙流都会继承那些修改，并会触发一次新的构建。
基于流的版本控制系统可以看作成一个树形结构的联合文件系统，在这个系统中，每个代码库都有一个根流，其他的流都继承自这个根流。
下面以一个例子说明如何使用基于流的版本控制系统，如下图所示。
在这个例子中，根流包含一个文件foo(修订版本是1.2)和一个空目录。两个子流Release 1和Release 2都继承自它。在Release 1上，可以看到继承的文件foo(修订版本是1.2)，以及两个新文件：a和b。在Release 2上，foo已经被修改过，修订版本是1.3，以及两个不同的文件：c和d。
两个开发人员各自在自己的工作区上对流Release 2进行开发。开发人员1正在修改文件c，开发人员2正在修改文件d。当开发人员1提交他的修改时，在Release 2上工作的每个人都可以看到他修改的c(修订版本是1.2)。如果子流Release 1也能看到修改的c(修订版本是1.2)，那么开发人员1就要将修改的c(修订版本是1.2)更新到根流上。此时，所有的子流上就都能够看到这个修改了。
- 分布式版本控制系统
分布式版本控制系统中每个使用者在自己的计算机上都有一个自包含的一等代码库，不需要一个专属的“主”代码库。著名的GitHub属于这种。
分布式版本控制系统具有以下特性：
- 可以单独从别人那里拿到他们的最新更新，却不需要他们将其修改提交到中央代码库。
- 可以将自己的修改推送到一组人的代码库中，而不需要他们每个人自己来拿你的修改。
- 补丁可以通过网络用户更高效地传播，这让接受或拒绝个别补丁变得很容易，即被叫做“摘樱桃”的实践。
- 当没有联网的时候，也可以对修改的代码进行版本控制。
- 可以频繁地提交未完成的功能到本地代码库作为阶段检查点，而不会影响到其他人。
- 在将修改发送给其他人之前，可以很容易地在本地对这些提交进行修改，重排它们的顺序或将多次提交打包成一个，这种操作叫做“rebasing”。
- 很容易用本地代码库来尝试各种各样的解决方案或想法，而不需要在中央代码库创建一个分支。
- 由于能在本地把多次提交打包，所以就不需要经常修改中央代码库。
- 在本地建立和同步多个代理库很容易，因此可以提供更高的可用性。
- 因为全量代码库有很多份副本，所以有更好的容错性。
分布式版本控制系统与中央版本控制系统的“通过中央服务器来保证几个人可以在同一时间在代码基的同一分支上工作”工作方式不同，分布式版本控制系统的每个本地代码库本身就是一个分支，而且也没有“主干”，是通过公开分支并相互合并的方式来交流代码。
使用分布式版本控制系统的一般流程如下：
- 从远程代码库中取回最新版本，放到本地代码库中。
- 用本地代码库的内容对本地工作副本进行更新。
- 编写/修改一些代码。
- 将本地修改保存到本地代码库中。
- 从远程代码库中获取新的更新。
- 用合并的结果更新本地工作副本，但不会签入这些合并。
- (如果实施持续集成)在本地运行提交构建。
- 将合并后的代码签入本地代码库。
- 将更新后的代码推送到远程代码库。
以上这三种版本控制系统各有特点，实施配置管理的组织可以根据组织的实际环境、版本控制特点等去选择适合自己的版本控制系统。
这正是：
配管工具有几多，各有特点分秋色
了解概念再试用，知己知彼作选择
参考书目：持续交付：发布可靠软件的系统方法，作者：[英]Jez Humble,David Farley，译者：乔梁，出版社：人民邮电出版社
