SVN分支管理模式探析
本文试图从SVN分支管理的结构模式、规则模式、使用场景、优缺点分析等几个方面阐述几种不同的分支管理模式。
结构模式——通过约束和指导项目的整体目录结构,实现并行开发的组织结构、开发模式及开发过程的约束和指导。
规则模式——通过对项目不同分支的相关的操作实施约束,如访问控制、分支合并及发布等操作的约束和指导。
一、 单主干-串行开发模式
1、使用场景
a) 你的系统只有一个版本发布给最终用户;
b) 你的维护方式是让客户不断升级到下一个版本;
c) 所有对系统的修改都必须包含在下一个版本中;
d) 已发布版本的bug是可控的,极少存在进行下一个版本开发过程中进行上一版本bug的修复工作。
2、图例
3、 结构模式
分支名称 | 源分支 | 开发方式 | 对应版本 |
trunk | 无 | 项目开发人员主要分支,其他人员无需使用该分支 | 当前正在开发的版本-Dev |
tags | trunk | 测试和发布专用分支,该分支代码不允许任何形式的修改 | 当前正在测试的版本-Test 当前已经发布的版本-R |
branches | ─ | ─ | ─ |
4、规则模式
a) 权限规则:Trunk分支对项目开发人员读写权限、tags分支对所有人只读权限、banches分支废弃不用或很少用。
b) 分支规则:开发人员直接在trunk上进行项目的开发,提测阶段从trunk上拉测试分支2010-12-15-1.0-T1到tags下,供测试人员进行测试;发布阶段从trunk上拉发布分支2010-12-15-1.0-R1到tags 下,供发布人员进行发布。
5、优缺点分析
a) 优点:分支结构简单、清晰;开发过程中无分支合并/冲突解决等操作
b) 缺点:不支持并行开发;不支持多版本发布。
二、 单主干多分支-并行开发模式
1、使用场景
a) 你的系统只有一个版本发布给最终用户;
b) 你的维护方式是让客户不断升级到下一个版本;
c) 所有对系统的修改都必须包含在下一个版本中;
d) 需要频繁的修改前一个发布版本的bug,以及不断开发新的版本。
2、图例
3、 结构模式
分支名称 | 源分支 | 开发方式 | 对应版本 |
trunk | 无 | 主干冻结,不允许开发 | 当前已经发布的版本-R |
tags | trunk | 测试和发布专用分支,该分支代码不允许任何形式的修改 | 当前正在测试的版本-Test |
branches | trunk | 开发专用分支 | 当前正在开发的版本-Dev |
4、规则模式
a) 权限规则:
l Trunk权限冻结开发,只有发布上线以后的版本才可以由SCM或SCM系统合并到trunk上;
l tags分支对所有人只读权限,用户测试、集成和发布分支用;
l banches分支是任何版本开发的唯一分支。
b) 分支规则:
l 任何开发版本发起,都必须从trunk上copy出分支到branches进行开发;
l 提交测试(集成、发布)必须先从trunk创建测试(集成、发布)分支,然后合并branches分支内容,保证trunk内容的更新及时反馈到集成;
l 发布阶段从trunk上拉发布分支2010-12-15-1.0-R1到tags 下,然后合并branches内容到tags,供发布人员进行发布,发布成功后,合并tags分支到trunk。Trunk完成一次发布升级。
5、优缺点分析
a) 优点:可以随时保证trunk上东西的稳定性,使trunk随时可用;可以从trunk上随时拿到已发布的任意一个版本。
b) 缺点:违背了SVN的规范,把trunk库当成了tag库去使用;分支合并频繁,导致冲突多,处理这些会消耗不少的资源,以及引入额外错误的可能;不支持多版本发布。
三、 多主干-串行开发模式
1、使用场景
a) 你的系统有多个版本发布给最终用户;
b) 每个版本的维护都是独立进行的,只在需要的时候才进行各版本的合并维护;
c) 已发布版本的bug是可控的,极少存在进行下一个版本开发过程中进行上一版本bug的修复工作。
2、图例
3、 结构模式
分支名称 | 源分支 | 开发方式 | 对应版本 |
trunk | 无 | 主版本的开发分支 | 当前正在开发的版本-Dev |
version | Trunk/version | 维护版本的开发分支 | 当前正在开发的版本-Dev |
tags | trunk | 测试和发布专用分支,该分支代码不允许任何形式的修改 | 当前正在测试的版本-Test 当前已经发布的版本-R |
branches | ---- | ----- | --- |
4、规则模式
a) 权限规则:Trunk和version分支对项目开发人员读写权限、tags分支对所有人只读权限、banches分支废弃不用或很少用。
b) 分支规则:开发人员直接在trunk或version上进行项目的开发,提测阶段从trunk或version上拉测试分支2010-12-15-1.0-T1到tags下,供测试人员进行测试;发布阶段从trunk或version上拉发布分支2010-12-15-1.0-R1到tags 下,供发布人员进行发布。
c) Version开发分支可以从trunk或其他version分支上创建而来。
d) 可以根据需要在version和trunk之间,或version之间合并代码。
5、优缺点分析
a) 优点:分支结构简单、清晰;开发过程中无分支合并/冲突解决等操作;支持多版本发布。
b) 缺点:不支持并行开发。
四、 多主干多分支-并行开发模式
1、使用场景
a) 你的系统有多个版本发布给最终用户;
b) 每个版本的维护都是独立进行的,只在需要的时候才进行各版本的合并维护;
c) 对每个维护版本都需要频繁的修改前一个发布版本的bug,以及不断开发新的版本
2、图例
3、结构模式
分支名称 | 源分支 | 开发方式 | 对应版本 |
trunk | 无 | 主干被冻结 | 当前已经发布的版本-R |
version | Trunk/version | 维护版本的主干,读写权限冻结 | 当前已经发布的版本-Dev |
tags | trunk | 测试和发布专用分支,该分支代码不允许任何形式的修改 | 当前正在测试的版本-Test 当前已经发布的版本-R |
branches | ---- | 开发专用分支 | 当前正在开发的版本-Dev |
4、规则模式
a) 权限规则:
l Trunk和version分支读写权限冻结,只有发布上线以后的版本才可以由SCM或SCM系统合并到trunk上;
l tags分支对所有人只读权限;
l banches分支是开发人员专用读写分支。
b) 分支规则:
l 任何开发版本发起,都必须从trunk或version上copy出分支到branches进行开发;
l 提交测试(集成、发布)必须把先从trunk或version创建测试(集成、发布)分支,然后合并branches分支内容,保证trunk或version内容的更新及时反馈到集成;
l 发布阶段从trunk或version上拉发布分支2010-12-15-1.0-R1到tags 下,然后合并branches内容到tags,供发布人员进行发布,发布成功后,合并tags分支到trunk或version。Trunk或version完成一次发布升级。
l Version维护主干分支可以从trunk或其他version分支上创建而来。
l 可以根据需要在version和trunk之间,或version之间合并代码。
5、优缺点分析
a) 优点:支持多版本发布;支持最复杂的分支开发情况;产品版本树规划清晰。
b) 缺点:版本和分支复杂,对产品版本树维护人员要求高。
五、 总结
1、 以上四种模式,对应我们B2B技术部的各个站点,大致情况如下:
对应站点/产品线 | SVN管理分支模式 | 备注 |
国际站/中文站/核心 | 单主干多分支-并行开发模式 | Branches开发 |
ASC-算法部门 | 单主干-串行开发模式 | Trunk开发 |
ASC-isearch平台 | 多主干多分支-并行开发模式 | Trunk-version-branches开发 |
平台 | 多主干-串行开发模式 | Trunk-version开发,平台目前是在branches下进行每个版本的开发和维护 |
数据仓库 |
|
|
ITBU |
|
|
2、 补充说明
a) 在本文的svn结构模式里,增加了一个version目录结构,这个目录结构在第四种分支管理模式中可以非常清楚的发现其作用:可以更加清晰的规划和显示产品的版本树,且和开发分支branches的功能区分开来。而在第三种分支管理模式中,在目前的操作中一般就是直接在branches下进行产品版本数的规划和维护。本文为了统一概念和系统实施的规划(例如Aone),还是建议统一增加versions目录。
b) 前面两种模式已经在aone上实现,第三钟模式目前平台在变相的使用,就是每次创建新的维护版本分支,都需要SCM在aone上添加新的主干应用/代码模块。如果增加了version目录结构,则可以设置规则,只要在version下的版本维护分支,则aone可以自动识别应用和代码模块,根据应用的分支开发管理模式(第三或第四种),决定是主干开发还是分支开发。
c) 第一种模式是第三种模式的特例;第二种模式是第第四种模式的特例。