SVN分支管理模式解析

1、svn分支管理模式探析本文试图从svn分支管理的结构模式、规则模式、使用场景、优缺点分析等几个方面阐述 儿种不同的分支管理模式。结构模式一一通过约束和指导项日的整体目录结构，实现并行开发的组织结构、开发模式及开发 过程的约束和指导。规则模式一一通过对项日不同分支的相关的操作实施约束，如访问控制、分支合并及发布等操作 的约朿和指导。单主干串行开发模式1、使用场景a）你的系统只有一个版本发布给最终用户；b）你的维护方式是让客户不断升级到下一个版本；c）所有对系统的修改都必须包含在下一个版本中；d）已发布版本的bug是可控的，极少存在进行下一个版本开发过程中进行上一版 本bug的修复工作。2、图例单

2、主干串行开发模式：trunk3、结构模式分支名称源分支开发方式对应版本trunk无项日开发人员主要分支，其他人员无 需使用该分支当前正在开发的版本-devtagstrunk测试和发布专用分支，该分支代码不允许任何形式的修改当前正在测试的版本-test当前已经发布的版本-rbranches4、规则模式a）权限规则：trunk分支对项目开发人员读写权限、tags分支对所有人只读权限、 banches分支废弃不用或很少用。b）分支规则：开发人员直接在trunk ±进行项冃的开发，捉测阶段从trunk ±拉测试 分支2010-12-15-1.0-t1到tags下，供测试人员进行测试

3、；发布阶段从trunk ±拉发 布分支2010-12-15-1.0-r1到tags下，供发布人员进行发布。5、优缺点分析a）优点：分支结构简单、淸晰；开发过程中无分支合并/冲突解决等操作b）缺点：不支持并行开发；不支持多版木发布。单主干多分支并行开发模式1、使川场景a）你的系统只有一个版本发布给最终用户；b）你的维护方式是让客户不断升级到下一个版本；c）所有对系统的修改都必须包含在下一个版本屮；d）需要频繁的修改前一个发布版本的bug,以及不断开发新的版本。2、图例单主干多分支-并行开发模式：branches3、结构模式分支名称源分支开发方式对应版本trunk无主干冻结，不允许开发当

4、前已经发布的版本-rtagstrunk测试和发布专用分支，该分支代码不允 许任何形式的修改当前正在测试的版木-test 当前已经发布的版本-rbranchestrunk开发专用分支当前正在开发的版本dev4、规则模式a）权限规则: trunk权限冻结开发，只有发布上线以后的版本才可以由scm或scm系统合并到 trunk tags分支对所有人只读权限，用户测试、集成和发布分支用；banches分支是任何版木开发的唯一分支。b）分支规则: 任何开发版本发起，都必须从trunk上copy出分支到branches进行开发； 提交测试（集成、发布）必须先从trunk创建测试（集成、发布）分支，然 后合

5、并branches分支内容，保证trunk内容的更新及时反馈到集成； 发布阶段从trunk上拉发布分支2010-12-15-1.0-r1到tags下，然后合并 branches内容到tags,供发布人员进行发布,发布成功后,合并tags分支到 trunko trunk完成一次发布升级。5、优缺点分析a）优点：可以随时保证trunk上东西的稳定性，使trunk随时可用；可以从trunk上 随时拿到己发布的任意一个版本。b）缺点：违背了 svn的规范，把trunk库当成了 tag库去使用；分支合并频繁，导 致冲突多，处理这些会消耗不少的资源，以及引入额外错误的町能；不支持多版 本发布。三、多主干串

6、行开发模式a）你的系统有多个版木发布给最终用户；b）每个版本的维护都是独立进行的，只在需要的时候才进行各版本的合并维护;c）己发布版本的bug是可控的，极少存衣进行下一个版本开发过程屮进行上一版 本bug的修复工作。2、图例tags多主干-串行开发模式：version-trunk3、结构模式分支名称源分支开发方式对应版本trunk无丄版本的开发分支当前正在开发的版本-devversi ontrun k/version维护版本的开发分支当前正在开发的版本-devtagstrunk测试和发布专用分支，该分支代码不允许任何形式的修改当前止在测试的版本-test当前已经发布的版本-rbranches

7、4、规则模式a）权限规则：trunk和version分支对项目开发人员读写权限、tags分支对所有人只 读权限、banches分支废弃不用或很少用。b）分支规则：开发人员el接在trunk或version上进行项目的开发，提测阶段从trunk 或version上拉测试分支2010-12-15-1.0-t1到tags下，供测试人员进行测试；发布阶段从trunk或version上拉发布分支2010-12-15-1.0-r1到tags卜，供发布人员进 行发布。c）version开发分支kl以从trunk或其他version分支上创建而来。d）可以根据需要在version和trunk之间，或versi

8、on之间合并代码。5、优缺点分析a）优点：分支结构简单、清晰；开发过程屮无分支合并/冲突解决等操作；支持多版 本发布。b）缺点：不支持并行开发。四、多主干多分支并行开发模式1、使川场景a）你的系统冇多个版本发布给最终用户；b）每个版本的维护都是独立进行的，只在需要的时候才进行各版本的合并维护;c）对每个维护版木都需要频繁的修改前一个发布版本的bug,以及不断开发新的 版本2、图例r!373、结构模式分支名称源分支开发方式对应版本trunk无卞干被冻结当前已经发布的版本-rversi ontrunk/versio n维护版本的主干，读写权限冻结当前已经发布的版本-devtagstrunk测试和发

9、布专用分支，该分 支代码不允许任何形式的 修改当前正在测试的版本-test当前已经发布的版本-rbranches开发专用分彳当前正在开发的版本-dev4、规则模式a）权限规则： trunk和version分支读写权限冻结，只有发布上线以后的版本才可以由scm 或scm系统合并至!1 trunk上； tags分支对所有人只读权限； banches分支是开发人员专用读写分支。b）分支规则： 任何开发版本发起，都必须从trunk或version上copy岀分支到branches进 行开发； 捉交测试（集成、发布）必须把先从trunk或version创建测试（集成、发布） 分支，然后合并branche

10、s分支内容，保证trunk或version内容的更新及时反 馈到集成； 发布阶段从trunk或version ±拉发布分支2010-12-15-1.0-r1到tags下，然 后合并branches内容到tags,供发布人员进行发布,发布成功后,合并tags 分支到trunk或version o trunk或version完成一次发布升级。 version维护主干分支可以从trunk或其他version分支上创建而來。 町以根据需要在version和trunk之间，或version之间合并代码。5、优缺点分析a）优点：支持多版木发布；支持最复杂的分支开发情况；产品版本树规划淸晰。b）缺

11、点：版本和分支复杂，对产品版本树维护人员要求高。五、 总结1、以上四种模式，对应我们b2b技术部的各个站点，大致情况如下：对应站点/产品线svn管理分支模式备注国际站/中文站/核心单主干多分支-并行开发模式branches 开发asc-算法部门单主干-串行开发模式trunk开发asc-isearch 平台多主干多分支-并行开发模式trunk-version-branches 开发平台多主干串行开发模式trunk-version开发，平台目前 是在branches下进行每个版本 的开发和维护数据仓库itbu2、补充说明a）在本文的svn结构模式里，增加了一个version目录结构，这个目录结构在第四种分支管理 模式中可以非常清楚的发现其作用：町以更加清晰的规划和显示产品的版本树，且和开发 分支branches的功能区分开來。而在第三种分支管理模式屮，在目前的操作中-般就是直 接在branches k进行产品版本数的规划和维护。木文为了统一概念和系统实施的规划（例 如aone）,还是建议统一增加versions 1=1录。b）前面两种模式己经在aone上实现,第三钟模式冃前平台在变相的使