分支管理定义
分支说明
核心原则：develop 和 master 两条主分支始终贯穿整个流程，禁止直接 commit 和 merge，必须通过 Pull Request 合入代码。
- master 分支：该分支上的代码随时可以部署到生产环境
- develop 分支：进行任何新开发的基础分支，并作为各个 feature 功能特性的集成分支
- feature/xxx 分支：每个新功能都在独立的 feature/xxx 分支上进行开发，开发完成后合并到 develop 分支
- release /x.y.z 分支：用于上线的准备工作和修改验收环境的 Bug，决不能包含需求变更或功能变更等重大修改
- hotfix/xxx 分支：用于快速修复线上 Bug，在 master 分支上创建，修改后合并回 master 和 develop 分支
分支汇总
| 分支 | 类型 | 用途 | 分支建立 | 分支合并 | 位置 |
|---|---|---|---|---|---|
| master | 长期分支 | 稳定版本 | 项目初始 | — | 本地，远程 |
| develop | 长期分支 | 开发版本 | 项目初始 | — | 本地，远程 |
| feature/xxx | 短期分支 | 新功能开发 | 从 develop 建立 | 开发完成合入 develop | 本地，远程 |
| release/x.y.z | 短期分支 | 预备发布 | 从 develop 建立 | 合并回 master 和 develop | 本地，远程 |
| hotfix/xxx | 短期分支 | 紧急 Bug 修复 | 从 master 建立 | 合并回 master 和 develop | 本地 |
| support/xxx | 短期分支 | 特殊版本 | 从 master 建立 | 一般不合并 | — |
分支使用注意事项
长期分支保护：develop 和 master 必须设置为 protected branch，杜绝直接 commit 和 merge 代码。
- feature/xxx 分支，建议通过项目管理工具上的 Feature 来创建关联 Feature 分支
- feature/xxx 分支粒度划分建议不超过一周，杜绝出现 long-lived-branches；每个 Sprint 结束删除原分支，重新拉取
- feature/xxx 分支建议每日从 develop 分支 pull 一次代码，发起 Pull Request 前均需要 pull 一次
- develop 分支上发现的阻塞问题，需半天内在 develop 分支上修复
- release/x.y.z 分支的命名原则为 release/x.y.z，x.y.z 与发布版本号保持一致，由 Feature Master 来创建、合入、删除
- 迭代验收后，release 代码及时回到 master 上
发布流程定义
环境与分支对应
| 环境名称 | 功能说明 | 分支 | 说明 |
|---|---|---|---|
| 开发（DEV） | 开发自测 | feature/xxx | 开发人员日常开发调试 |
| 集成（SIT） | API 测试 + UI 测试 | develop | 功能集成后的系统测试 |
| 验收（UAT） | API 测试 + UI 测试 + 迭代验收 | release/x.y.z | 产品验收测试 |
| 预生产（STG） | 预生产验证/演示 | tag | 基于 master 打 Tag 部署 |
| 生产（PRD） | 正式生产 | tag | 基于 master 打 Tag 部署 |
发布流程步骤
- 上 SIT 环境：从 feature 通过 Pull Request 到 develop 分支，进行 SIT 测试
- 上 UAT 环境：从 develop 通过 Pull Request 到 release 分支，进行 UAT 测试，产品负责人做迭代发布验收
- 上预生产/生产环境：从 release 发起 Pull Request 到 master 分支，测试验证通过后打 Tag 部署，进行冒烟测试，产品负责人做版本发布验收
- 灰度发布：用于生产上线前按照版本或地域实现流量切换验证
代码提交频率
| 分支 | 频率要求 |
|---|---|
| feature | 每天至少一次 |
| develop | 2 天至少一次 |
| release | 平均每周一次 |
| master | 平均每个迭代（2 周）一次 |
验收分支定义
- 迭代验收：release 分支，产品负责人验收
- 版本 发布验收：master 分支，产品负责人验收
SDK 包管理规范
分支 约束：POM 文件中 artifact 的 version 取值，在研发测试阶段用 -SNAPSHOT 后缀，合入 master 分支时去除 -SNAPSHOT 后缀（Code Review 检查）。
SDK 版本号命名
Java 包（Maven） 版本 字符串：major.minor.build-profile
- major、minor、build 都是数字，profile 取两个值：SNAPSHOT、RELEASE
- 大版本不兼容更新，升级 major（升级后 minor 和 build 回到 0）
- 兼容性的功能增强，升级 minor（升级后 build 回到 0）
- Bug 修复，RELEASE 版本必须升级 build，SNAPSHOT 版本可以不用升级 build
前端 ****JavaScript 包（npm） 版本 字符串：major.minor.build
- major、minor、build 都是数字不带 profile，数字升级规则与 Java 包的 RELEASE 一致
管理原则
- Snapshot 依赖原则：提交 master 分支代码时，必须去除 pom.xml 中 snapshot 类型的依赖
- Deploy 方式：snapshot 和 release 版本都要求通过 CI 流水线配置脚本实现，其中 release 版本要求拉取 master 分支 Tag 版本
- 权限控制：Web 界面仅提供开发人员 View 权限；命令行允许开发人员执行 deploy 部署；三方库包需经审批上传；默认不允许覆盖或删除已 deploy 的文件
软件版本说明
版本号规则
版本号遵循 RX.Y.Z.B 规则：
| 字段 | 含义 | 说明 |
|---|---|---|
| X | 重大增强类变更号 | 注册版本 |
| Y | 轻微增强类变更号 | M 版本号 |
| Z | 纠正类变更号 | H 版本号 |
| B | 构建变更号 | 每次发布大版本后 +1 |
示例：R001.5.2.000001
版本包规则
软件版本号命名格式：{类型}-{产品模块名}-{MxHz}-RX.Y.Z.B-{日期}
| 字段 | 说明 |
|---|---|
| 类型 | FULL（完整包）或 Hotfix（补丁包） |
| 产品模块名 | 对应产品模块标识 |
| MxHz | 版本号（如 M8H1） |
| RX.Y.Z.B | 详细版本号 |
| 日期 | 构建日期（YYYYMMDD） |
Tag 命名规范
与软件包命名规则类似，移除包类型及产品名：RX.Y.Z.B-{日期}
注意：针对 Tag 出包该处为 Tag 号，若为分支出包则由流水线管道自动生成。
Hotfix 管理
Hotfix 用于紧急修复生产环境问题，需严格控制范围，仅包含 Bug 修复，不得引入功能变更。
- 完整包命名：
FULL-{模块名}-MxHz-RX.Y.Z.B-{日期}.tar.gz/exe - 补丁包命名：
Hotfix-{模块名}-MxHz-RX.Y.Z.B-{日期}.tar.gz/exe - 部署脚本及说明文档放压缩包根路径下
