第22章　Topgit协同模型

22.1　作者版本控制系统的三个里程碑

如果在卖主分支上导入上游的新版本v3.0，合并将会非常痛苦。因为主线上针对不同需求的定制开发已经混杂在一起了！

实践证明，Subversion的卖主分支对于大规模的定制开发非常不适合。向上游新版本的迁移会随着定制功能和提交的增多变得越来越困难。

2.Hg和MQ

在2008年，我们的版本库迁移到Mercurial（水银，又称为Hg），并工作在"Hg+MQ"模式下，我自以为找到了定制开发版本控制的终极解决方案，那时我们已被Subversion的卖主分支折磨得太久了。

Hg和Git一样也是一种分布式版本控制系统，MQ是Hg的一个扩展，可以实现提交和补丁两种模式之间的转换。Hg版本库上的提交可以通过hg qimport命令转化为补丁列表，也可以通过hg qpush、hg qpop等命令在补丁列表上游移（出栈和入栈），入栈的补丁转化为Hg版本库的提交，补丁出栈会从Hg版本库移走最新的提交。

相比Subversion的卖主分支，使用"Hg+MQ"的好处在于：

针对不同需求的定制开发，其提交被限定在各自独立的补丁文件中而不会混杂在一起。

针对同一个需求的定制开发，无论多少次的更改都体现为补丁文件的变化，而补丁文件本身也是被版本控制的。

各个补丁之间是顺序依赖关系，形成一个Quilt格式的补丁列表。

向上游新版本迁移过程的工作量降低了，除了因为针对各个功能的定制开发被隔离，还有迁移过程也非常具有可操作性。

将定制开发迁移至上游新版本的过程是：先将所有补丁“出栈”，再将上游新版本提交到主线，然后依次将补丁“入栈”。如果上游新版本的代码改动较大，补丁入栈可能会遇到冲突，在冲突解决完毕后执行hg qref命令即可完成定制开发到新的上游版本的迁移。

但是如果需要在定制开发上进行多人协作，"Hg+MQ"的弊病就显现了。因为"Hg+MQ"工作模式下，定制开发的成果是一个补丁库，在补丁库上进行协作的难度非常大，当发生冲突的时候，补丁文件本身的冲突会让人眼花缭乱。这就引发了我们第三次版本控制系统大迁移。

3.Git和Topgit

2009年，我们把目光锁定在Topgit上。Topgit是Topic Git的简写，是用shell脚本语言开发的辅助工具，对Git功能进行了扩展，用于管理特性分支的开发。Topgit为特性分支引入了基准分支的概念，并以此管理特性分支间的依赖，让特性分支向上游新版本的迁移变得非常简单。

Topgit的主要特点有：

上游的原始代码位于开发主线（master分支），而每一个定制开发都对应于一条Git特性分支（refs/heads/t/feature_name）。

特性分支之间的依赖关系不像"Hg+MQ"那样是逐一依赖模式，而是可以任意设定

[1]http://repo.or.cz/w/topgit.git