代码分支及版本管理规范

目的

为了规范代码库分支管理 和 版本管理，使代码分支及版本结构清晰，方便维护，并避免由于维护造成的错误的版本发布等问题。

适用范围

适用于Lifeix所以项目。

规范

 

Git 分支管理

     通常每个应用或者是二方库的代码将包括 master、develop、release、hotfix、feature分支，release、hotfix 分支的命名规则分别为：release-*，hotfix-*。feature分支的命名可以使用除master，develop，release-*，hotfix-*之外的任何名称。

          

 

 

        各分支使用办法说明如下：

 

master分支

master和develop分支都是主分支，主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。

master分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。当开发活动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。同时，每一次更新，都有对应的版本号标签（TAG）。

develop分支

 develop分支是保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码（Nightly build）。因此这个分支有时也可以被称作“integration branch”。

 当develop分支上的代码已实现了软件需求说明书中所有的功能，通过了所有的测试后，并且代码已经足够稳定时，就可以将所有的开发成果合并回master分支了。对于master分支上的新提交的代码建议都打上一个新的版本号标签（TAG），供后续代码跟踪使用。

release分支

使用规范：

• • 可以从develop分支派生
  • 必须合并回develop分支和master分支
  • 分支命名惯例：release-*

release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。

当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷）。

成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。

hotfix分支

使用规范：

• • 可以从master分支派生
  • 必须合并回master分支和develop分支
  • 分支命名惯例：hotfix-*

除了是计划外创建的以外，hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。

feature分支

使用规范：

• • 可以从develop分支发起feature分支
  • 代码必须合并回develop分支
  • feature分支的命名可以使用除master，develop，release-*，hotfix-*之外的任何名称

feature分支（有时也可以被叫做“topic分支”）通常是在开发一项新的软件功能的时候使用，这个分支上的代码变更最终合并回develop分支或者干脆被抛弃掉（例如实验性且效果不好的代码变更）。

一般而言，feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。

 

版本号管理

 

1. 版本号命名规则

 

a.  库结构版本号

版本号的格式：w<主版本号>.<副版本号>.<发布号>/t<主版本号>.<副版本号>.<发布号>

版本号的初始值：w1.0.0/t1.0.0

管理规则:

♦ 主版本号（Major version）

1．设置时间：数据库结构处理完毕，待发布给相关组之前确定。

2．设置部门：开发组设定（告知数据结构管理员）。

3．设置规则：

1） 涉及到大于10个表的增删时，主版本号加1；

♦ 副版本号（Minor version）

1．设置时间：数据库结构处理完毕，待发布给相关组之前确定。

2．设置部门：开发组设定（告知数据结构管理员）。

3．设置规则：

1） 主版本号变更时，副版本号置0。

2） 涉及到小于等于10个表或字段的增删时，副版本号加1；

3） 若副版本号累加至超过20时，采用主版本号进位制，主版本号加1，副版本号重新置0；

♦ 发布号（Release）

1．设置时间：数据库结构处理完毕，待发布给相关组之前确定。

2．设置部门：开发组设定（告知数据结构管理员）。

3．设置规则：

1）主版本号或副版本号变更时，Release号置0。

2）仅涉及字段含义调整、标置位的含义、索引和同义名调整时，则Release号加1；

b.  业务版本号

版本号的格式：w<主版本号>.<副版本号>.<发布号>/t<主版本号>.<副版本号>.<发布号>

版本号的初始值：w1.0.0/t1.0.0

管理规则:

♦ 主版本号（Major version）

1．设置时间：产品预计发布时。

2．设置部门：开发组设定。

3．设置规则：

1） 产品的主体构件进行重大修改，主版本号加1；

2） 产品的主体构件之间的接口协议重大修改，主版本号加1。

♦ 副版本号（Minor version）

1．设置时间：产品预计发布及版本预计更新时。

2．设置部门：开发组设定。

3．设置规则：

1） 主版本号变更时，副版本号置0；

2） 数据结构变更(新增或修改注释含义的情况除外)，副版本号加1；

3） 若副版本号累加至超过20时，采用主版本号进位制，主版本号加1，副版本号重新置0。

♦ 发布号（Release）

1．设置时间：产品预计发布及版本预计更新时。

2．设置部门：开发组设定。

3．设置规则：

1）主版本号或副版本号变更时，Release号置0；

2）若发布的版本无数据结构变更，则Release号加1。

 

注：主版本号和副版本号的变更标志着重要的功能或结构变动。Release号的变更，用于体现小的功能变更或用来管理项目的分支。

2. 项目周期内版本号变化规则

        

目前我们使用工程集的方式使用maven组织源代码项目过程中将涉及到一个war包及其依赖的子工程的版本协调问题，其版本号变化原则如下：

a、xxx.war 的版本号变化规则是：在每个web应用程序的迭代周期开始时主版本号 增1，次版本号和发布号都从0开始。

b、xxx.web 的版本号变化规则是：在每个web应用程序的迭代周期内，只有当其代码有变更的时候才变化其版本号，其版本号与xxx.war保持一致。

c、xxx.impl 的版本号变化规则是：在每个web应用程序或者java应用程序的迭代周期内，只有当其代码有变更的时候才变化其版本号，其版本号与xxx.war保持一致。

d、xxx.service 的版本号变化规则是：在每个web应用程序或者java应用程序的迭代周期内，只有当其代码有变更的时候才变化其版本号，其版本号与xxx.war保持一致。

e、xxx.dao 的版本号变化规则是：在每个web应用程序或者java应用程序的迭代周期内，只有当其代码有变更的时候才变化其版本号，其版本号与xxx.war保持一致。

f、xxx 的版本号在其子工程内代码有变化的情况下都将随之变化， 其版本号与xxx.war或者xxx.task保持一致。

g、为避免war和task的版本号重复，war子工程及随war变化的子工程的版本号以“w”开头，task子工程及随task变化的子工程的版本号以“t”开头，

 

3.项目周期内版本号变化规则

开发阶段版本号后面要加 snapshot

到提测试的时候每次打包 RC后缀加1

 

注：

Alpha：是内部测试版,一般不向外部发布,会有很多Bug.一般只有测试人员使用。

Beta：也是测试版，这个阶段的版本会一直加入新的功能。在Alpha版之后推出。

RC：(Release　Candidate) 顾名思义么 ! 用在软件上就是候选版本。系统平台上就是发行候选版本。RC版不会再加入新的功能了，主要着重于除错。

GA:General Availability,正式发布的版本，在国外都是用GA来说明release版本的。