thinkernel的博客

关于源代码版本控制中的分支运用

关键词： 版本控制    配置管理                                          

这两天抽时间把《软件发布方法》里面关于源代码控制的章节看了一边。得到了一点提示。
目前项目面临的一个问题就是对于同一个机能里的程序存在设计变更、内部连接测试、外部连接测试3方面的修改需要同时对应，而且整个项目的所有机能正在进行品质向上的工作。因为测试的周期性，导致必须要等所有的变更同时完成才能够集成到下一个阶段的外部连接测试中去。
当初面临这个问题的时候首先想到的就是进行分支管理。但是定不下一个好的分支管理策略，而且担心合并产生的风险，最终还是没有采用。
从《软件发布方法》里得到了一点思路。可以按照变更和bug为单位进行分支，在变更或者bug的对应单体测试完成以后再合并到主干上。
更 具体一点讲，在开发团队确定下某个变更ID或者BugID需要修正的源代码范围以后，向配置管理人员提交变更申请，配置管理人员从主干上，对要发生变更的源代码 群进行分支，分支名应该就是变更或者bug的ID。然后开发人员在分支上进行修正以及单体测试。通过以后提交合并申请。由配置管理人员完成向主干的集成。然后 再从主干上checkout代码进行内部连接测试。这样的话，即使同一个代码同时有好几个变更在进行，也可以互不影响。从一定程度上能够提高对应的速度。 唯一的风险就是合并。但是合并以后的代码如果进行内部连接测试的话，应该能够发现合并造成的错误。当然，负责合并集成的人应该经验比较丰富。
而品质向上的工作应该在主干上就能够直接进行。然后只要把分支上对应修改的时候发生的代码变更集成到主干上就可以了。当然，在合并完成以后，对合并以后的源代码还是需要进行一下品质向上检查的。这就增加了一些工作量。
上面的分支策略产生的分支可以被叫做任务分支。另外还有一种分支叫做集成分支。这两种分支可以并存。
对于我们的项目来说，每周末向外部连接测试的下一个cycle发布的代码都可以采用集成分支的方法。目前因为每次发布后如果出现错误在主干上直接修正，所以没有用分支，而是采用标签的方法标注每一次发布的内容。

【作者: thinkernel】【访问统计:】【2005年11月13日 星期日 16:56】【 加入博采】【打印】