吉利能力中台项目上线在即，为规范上线后的代码分支管理和版本管理，制定如下规范，请大家review，有问题先异步反馈，后面会安排专题会议讨论确定。
产品部分的代码分支管理和版本管理是否与项目交付保持一致也请提前考虑下。
一、项目环境定义
吉利能力中台项目周期内涉及dev、sit、uat、tra、prod 5套环境，各环境定义及使用说明如下：
1. 开发环境（dev）
用于需求开发、联调。由开发人员自行发布。
2. 测试环境（sit）
用于数跑内部验收测试。由各模块开发Leader发布，验收测试期间不允许变更版本。
3. UAT环境（uat）
用于吉利IT/业务验收测试。受控发布，由运维按固定时间窗口统一发布，验收期间不允许变更版本。
4. 公测/预发布环境（tra）
用于对外公测、预发布验证、线上问题复现及回归。受控发布，由运维按固定时间窗口统一发布。
5. 生产环境（prod）
线上正式环境。受控发布，前期由运维按固定时间窗口统一发布，后续由运维统一出口，提交吉利运维执行发布。
二、代码分支管理
1. 每个工程存在两个长期分支：develop、master。develop分支为所有开发完成的代码，master分支为所有验收通过，可对外发布的代码。
2. 其他分支均为临时分支，包括feature分支、pre-release分支、bugfix分支。
3. develop、master分支为受控分支，由各中心负责人控制合入，其余开发人员需合入develop、master分支时，提交Merge Request（需详细描述合入内容）给各自中心负责人，
各中心负责人review并check后合入。
4. develop、master分支命名不允许修改，其他分支命名不能和develop、master分支重名，分支名中不允许出现中文。
feature分支命名建议：feature-迭代名/需求编号，如feature-sprint1、feature-srs001。
pre-release分支命名建议：pre-release-版本号，如pre-release-1.0.0。
bugfix分支命名建议：bugfix-缺陷编号/问题单编号，如bugfix-4060。
4. 迭代开始或特性需求开发前，由各中心负责人基于当前develop分支拉出feature特性开发分支，开发人员基于feature分支进行特性需求开发。
迭代结束或需求开发、联调完成后，由各中心负责人及时将feature分支合回develop分支，feature分支失效删除。
5. 提交验收测试前（包括SIT内部验收测试、UAT客户方验收测试），由各中心负责人基于当前develop分支拉出pre-release分支，并发布RC标签版本，同时在代码仓库中创建对应的Tag标签（需详细描述对应内容）。
验收测试期间，pre-release分支只允许合入问题修复代码，不允许合入新特性需求代码。
验收测试通过后，由各中心负责人将pre-release分支合入master分支、develop分支、feature分支（可选），pre-release分支失效删除。
6. 基于项目上线计划，各中心负责人基于master分支发布正式标签版本，同时在代码仓库中创建对应的Tag标签（需详细描述对应内容）。
7. 线上问题修复时，基于线上版本对应的正式标签版本（Tag）拉出bugfix分支，基于bugfix分支进行问题修复及验证。
验证通过后，由问题修改人提交Merge Request给各中心负责人，申请将bugfix分支合入develop分支、master分支、feature分支（可选），各中心负责人review并check后进行合入，bugfix分支失效删除。
bugfix分支只允许合入指定线上问题修复代码，不允许其他问题修复代码和新增特性需求代码。
三、版本号规范
1. 版本号命名统一遵循如下命名规则
MCC-主版本号.次版本号.子版本号[-RC | -SNAPSHOT]
主版本号：由数字组成，从1开始，当模块功能、架构、数据模型发生重大变化或是涉及不兼容修改时修改主版本号。主版本号修改时次版本号和子版本号复位。
次版本号：由数字组成，从0开始，当新增重要功能，或架构有较为主要的调整时，且修改兼容时修改次版本号。次版本变化时主版本号不变，子版本号复位。
子版本号：由数字组成，从0开始，局部功能扩充或修复bug时，主版本号和次版本号不变，子版本号单步增加。
举例如下：
开发版本：MCC-1.1.0-SNAPSHOT
候选版本：MCC-1.1.0-RC
正式版本：MCC-1.1.0
2. dev环境统一使用SNAPSHOT开发版本。
3. sit、uat环境用于验收测试的版本统一使用RC标签版本。
4. tra、prod环境统一使用正式发布标签版本。
网友评论