一个分支模型

今天上午在做分支合并，刚开始只是照着邮件做就罢了。仔细看过邮件，觉得有些蹊跷的地方，特意写出来和大家讨论一下。

邮件中提到“对于Hawkeye、poncat、alleycat分支源码以后将每周安排专人合并一次”，也就是说，每周要对3个分支进行两两合并，一共需要合并6次，这本身就是艰巨的活。仔细想想，为什么会有这三个分支呢？

当然理由大家都清楚，为了发布，不要将其它分支修改引入到将要发布的分支。如果这样每周3个分支两两合并一次，那么还能够达到隔离的目的吗？我想，最后的结果是，某个分支要集成测试了，其它分支就不能够再往这个分支合并了。这样留下两个问题：

带着这些问题，我重新读了《一个成功的git分支模型》一文（我自己是一个重度git患者）。虽然git和svn是不同的版本控制系统，但其中版本控制分支管理的思想是可以有些相同的。

我个人觉得，我们为什么会出现这样分支难以管理的问题：分支以机型不同划分，没有加入软件开发步骤的划分。下面我就将机型划分和软件开发步骤划分结合，得到下面这样一个分支模型：

就该分支模型说明如下：

从左到右依次为新平台/功能开发分支，Trunk分支，Release分支。
新平台，功能分支应该在适当的时候合并到Trunk分支。例如，我们现在的poncat分支是从Trunk分支上分出，为了开发poncat分支这个新平台，在讲新平台部分的功能开发结束之后，就应该合并到trunk分支，不应该在该分支上发布集成测试，更不能够由release版本（仔细想想这是为什么？）。否则，就会导致该分支不能够结束，只要该项目一直存在。
Trunk分支，顾名思义就是主干分支（其实应该叫做develop分支）。产品线内部集成测试的bug都在该分支上修改，在没有建立相应机型的release分支时，所有的bug都在该分支上修改。规模较小的重构，功能完善也在该分支上修改。该分支也是产品线自动化测试每周（每日）构建的代码源。
release分支，在适当的时候（这里定义是bug<30）从trunk分支分出。对该分支只做bug修复，并且所有的修复都得同时向trunk分支合并。该分支直到发布版本就算结束，应该删除（或者放入version分支，如果有的话）。

下面来看看现在这模型是如何解决现有分支模型存在的问题：

作为bug修复工程师，分支多，一个bug需要多个分支修改（或者合并）：现在只需要关心两个地方的bug，一个是Trunk分支，一个是release分支；只需要做一次合并，release分支的修改向trunk分支合并。
作为release发布工程师，通过建立release分支隔离了其它bug修复对版本发布的影响；在适当的时候建立release分支又可以获取其它机型bug的修复结果。

当然，这种分支模型也有明显的不足，思考当同时有多个release分支进行会怎么样。

上面内容表述可能有模糊的地方，感谢阅读。如果还能够指出其一二，万分感谢。