多业务线下的代码版本管理控制与研发流程规范

一、版本管理流程

1. 主干分支（main）: 研发的分支从主干检出、经过测试（UAT）验收后必须要合并到main分支上，并且需要发布到UAT环境上再次验收，方可发布， 此分支名称固定为main，每个业务线只存在一个。

2. 功能分支（feature）: 需求研发、功能迭代、缺陷修复、处于研发中的分支。此分支名称按版本规范命名， 每个业务线允许多个存在。

3. 测试分支（uat）: 发布到测试环境的分支，任何研发修改，都需合并到此分支进行测试验证。 此分支名称固定为uat，每个业务线只存在一个。

二、各业务线运作规范

1. 每个业务线包含自己的main、uat和feature分支， 例如：

   国内业务：
   1） main 分支： main_china
   2) feature分支： internation_1.0.0_SNAPSHOT
   3) uat分支： uat_internation

   国际业务：
   1） main 分支： main_internation
   2) feature分支： internation_1.0.0_SNAPSHOT
   3) uat分支： uat_internation

2. 如果各业务线有共性需求，处理流程：

   国内业务的 china_1.1.0_SNAPSHOT -> 合并至国际业务的uat_internation -> 验证后合并至国际业务的main_internation (从china_1.1.0_SNAPSHOT 合并)

三、版本命名规范

1. 完整版本格式

   主版本号.次版本号.修订号-版本类型 【eg: 1.0.0-SNAPSHOT】

2. 主版本号： 项目级主导的规划实现。

   对应：项目级需求【eg: 1.0.0-SNAPSHOT，2.0.0-SNAPSHOT … X.0.0-SNAPSHOT】

3. 次版本号：功能性的新增与修改。

   对应：功能级需求 【eg: 1.0.0-SNAPSHOT，1.1.0-SNAPSHOT … 1.X.0-SNAPSHOT】

4. 修订号：面向问题的修正处理。

   对应： BUG级缺陷修复【eg: 1.0.1-SNAPSHOT，1.0.2-SNAPSHOT … 1.0.X-SNAPSHOT】

5. 版本号名称说明：

   1）SNAPSHOT : 快照版本，标识处于研发阶段，该版本可能存在未完成的功能或还需修复的bug，概念上对应dev分支。

   2）HOTFIX：修复版本， 针对临时缺陷或生产问题修复。

   3）BETA：测试版，发布测试的版本，概念上对应uat分支的测试。

四、版本合并管理规范

合并原则：

1. 开发分支（feature）都是基于主干分支（main）检出。
2. 开发分支（feature）可以合并至UAT分支进行测试， 验收成功后可以合并至主干分支（main）回归。
3. 测试分支（uat）不可以合并至其他任何分支， 验收后的分支，通过开发分支（feature）进行合并。

合并权限管控

1. 权限合并至允许负责人操作， 研发人员不能直接操作，负责人通过gitlab管控好权限。
   

2. 涉及到合并处理的两个环节， 一是提测时的合并， 二是测试通过回归验证的合并， 负责人必须做好审核， 避免代码合并出现的版本错乱与多模块关联性问题。