一、版本管理流程
- 主干分支（main）: 研发的分支从主干检出、经过测试（UAT）验收后必须要合并到main分支上，并且需要发布到UAT环境上再次验收，方可发布， 此分支名称固定为main，每个业务线只存在一个。
- 功能分支（feature）: 需求研发、功能迭代、缺陷修复、处于研发中的分支。此分支名称按版本规范命名， 每个业务线允许多个存在。
- 测试分支（uat）: 发布到测试环境的分支，任何研发修改，都需合并到此分支进行测试验证。 此分支名称固定为uat，每个业务线只存在一个。
二、各业务线运作规范
1、每个业务线包含自己的main、uat和feature分支， 例如：
国内业务：
1） main 分支： main_china
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分支的测试。
四、版本合并管理规范
合并原则：
- 开发分支（feature）都是基于主干分支（main）检出。
- 开发分支（feature）可以合并至UAT分支进行测试， 验收成功后可以合并至主干分支（main）回归。
- 测试分支（uat）不可以合并至其他任何分支， 验收后的分支，通过开发分支（feature）进行合并。
合并权限管控
1、权限合并至允许负责人操作， 研发人员不能直接操作，负责人通过gitlab管控好权限。
2、及到合并处理的两个环节， 一是提测时的合并， 二是测试通过回归验证的合并， 负责人必须做好审核。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。