分支的在配置管理工具的重要性是显而易见，包括CC，HAVERST等等重量级工具都有分支的影子，只是叫法不一样而已，一个优秀的配置管理工程师，首先要对分支进行生入的理解，谢谢大家捧场！今后，我会陆续把我们公司的分支模式奉献给大家，一句话，没有最好的，只有最合适的！

[ 本帖最后由 daiqiang 于 2007-7-3 19:30 编辑 ]

若要配合图，有些简要的文字说明的话，就更好啦！
例如维护分支的缺陷的修复，与test分支的缺陷有什么不同吗？
还请赐教！

看这张图应该是维护分支的缺陷修复针对release发现的缺陷，而测试产品的缺陷修复针对产品的Alpha测试中用户所发现的缺陷。还请各位指正。

对于这个分支模式的解释：
首先，一个团队角色比较齐全的公司，一般会包括软件开发工程师，软件配置工程师，软件测试工程师，架构师，项目经理或者程序经理等等。在开发过程中，经常与代码打交道就是软件开发工程师，软件配置工程师，软件测试工程师这三种角色，软件开发工程师负责代码的变更，配置工程师负责代码的集成/构建/发布等工作，测试工程师负责软件的测试。比较有实力的企业，比如微软，测试工程师不但人多，而且可以直接进行代码级白盒测试。
其次，上面这幅图就是对应这三种主要的角色，开发工程师对应develope分支，在这个分支上对代码进行变更操作，配置工程师对应release分支，这个分支负责merge/集成develope分支上的代码，并根据发布技术，及时进行构建发布工作，test分支就由测试工程师负责，可以在这个分支上加入测试框架等等工作，为什么test分支是灰色的，因为我们公司没有实力组织像微软一样强大的测试队伍，可以不建立test分支。
最后，大家要看下代码meger/归并的方向，test分支的缺陷是在开发过程发现的，release上分支的缺陷是产品发布后的发现的。

[ 本帖最后由 daiqiang 于 2007-7-4 13:14 编辑 ]

firefly分支实例示意图

之前就有点疑惑，对于test分支，为什么只有在Alpha版本出来的时候才有测试的过程，后来楼主说test分支中的缺陷是开发过程中发现的缺陷，但是我觉得图中并没有反映出对于build的测试过程，而只看到了Alpha版本的测试。按图上看来，白色的圆圈就是一个内部测试的build，而每一个向release归并的build，并没有在test分支上体现出测试过程就直接归并了，这一点就是我不解的地方。可能是在下愚钝，还请楼主指点。

对于不同公司,不同业务项目,分支模式是不一样的,我个人认为,test分支主要有测试工程师负责,a版本是表示软件产品框架基本稳定,并实现了部分需求,这时候,测试工程师介入白盒测试比较合适.同时,上面只是一示意图而已,大家可以借鉴,但不能照搬

[ 本帖最后由 daiqiang 于 2007-7-5 10:18 编辑 ]

呵呵,首先很感谢楼主能够提供这些图,但还希望在对图进行描述的时候说得更详细一点,能够在有的地方对应自己公司的特点.不然大家看起来的话概念就不是那么清楚了.比如针对alpha版本,楼主这边指的是软件产品框架基本稳定,并实现了部分需求,让测试工程师进行白盒测试,但有的公司就是版本发布前让用户进行测试.所以我就对这张图中的内部测试比较疑惑.楼主贴图的目的也是想让大家对分支的理解更深入,有些概念解释清楚之后大家就会理解得更轻松一点.我想rocky_rup应该也是这个意思.
最后还是要感谢楼主如此细致的图,受益了.

真奇怪了，为什么我们公司一直都没用到分支呢。

引用:

原帖由 kaixintuzi2003 于 2007-7-30 13:57 发表
真奇怪了，为什么我们公司一直都没用到分支呢。

说明单兵作战能力甚高