工程分支&版本管理规范

hotfix修复分支

tag-1.x.x-yyMMdd

工程分支&版本管理规范

新建分支hotfix/1.0.2.1

1.0.2.1.1

tag-1.0.1-200423

release 预发分支

release/1.0.1.2

合并代码

功能开发

feature/1.0.2.1.2

自测验证

主版本号

发布部署

tag-1.0.1.1-200429

测试验证

新建分支feature/1.0.3.1.1

目前由于对外API接口是作为整个maven工程的一个子模块存在，所以API工程的版本和主工程的版本保持一致，规则相同按照目前的Feign接口请求处理方式，API接口工程仅是一个请求接收壳，真正的接口功能是在项目主工程中实现的，一旦对外接口需要调整（新增、修改、删除），必然涉及到主工程相应代码的改动，所以starter和主工程同版本是有必要的API接口变更后，需要提醒接口调用方及时调整API工程依赖版本

release/1.0.2.2

新建分支hotfix/1.0.1.1

研发修复

分支命名规则：hotfix/${Mversion}.${SUBversion}分支来源：最新发布上线后打tag标签例1：新建紧急修复分支：hotfix/1.0.2.1说明：1）hotfix 表示该分支是生产问题紧急修复分支2）1.0.2 ：表示主工程pom的版本version，（该版本号主版本号、次版本号来源于最新发布的tag版本）3）最后一位 1：表示修订版本号从1递增

feature开发/联调分支

修订版本号

新建分支feature/1.0.2.2.1

hotfix（问题紧急修复）分支

1.预发布分支、开发/测试分支在开发、测试、业务验证阶段需实时同步master主干代码到当前分支2.预发布分支、开发/测试分支、问题紧急修复分支在开发、测试、业务验证阶段时工程pom中均以{version}-SNAPSHOT快照版构建3.待功能验证无误后以{version}-RELEASE （该变更看运维有无途径动态设置，如没有现阶段由研发手工调整）版本构建正式生产部署版本4.预发布分支、问题紧急修复分支发布完成后，需同步分支代码到master主干，开发/测试分支待预发布分支上线后，即可删除5.预发布分支保留3个版本，问题紧急修复分支保留3个版本

release/1.0.1.3

分支命名规则：release/${Mversion}分支来源：master例1：新建测试分支：release/1.0.2 说明：1）release：   表示该分支是需要测试验证的分支，验证完毕后可进入预发的分支2）1.0.2    :    表示主版本version，常规测试分支主版本号与产品版本号保持一致

新建分支release/1.0.3

次版本号

（1）主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生变化，此版本号由项目决定是否修改。面向大需求。（2）次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强，面向小需求。（3）修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩充，要经常发布修订版，修复一个严重 Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。

新建分支release/1.0.2

feature 开发/测试分支：

新建分支feature/1.0.2.1.1

release测试分支

tag-1.0.3-200521

新建分支release/1.0.1

tag-1.0.2.1-200510

master主干

分支命名规则：b style=\

新建分支release/1.x.x

tag-1.0.2-200507

RPC工程版本的补充说明

新建分支feature/1.x.x.1.1

release/1.0.2.1

feature/1.0.2.1.1 开发、自测完成后，font color=\"ff0000\

版本号修改规则：