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