SVN分支

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   当前已经发布的版本-R
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)         第一种模式是第三种模式的特例；第二种模式是第第四种模式的特例。