基本概念
Multirepo架构
每个项目/模块独立存放（如admin-components仓库）
分支管理（Branch）
对 Git 分支的使用进行说明。
分支类别
| 分支类型 | 分支命名 | 功能说明 |
|---|---|---|
| 主分支（长期保留） | master | 主分支： 用于同步最新代码，发版负责人负责每次版本发布完成后将 release 分支合到 master |
| 版本发布分支（长期保留） | release/{日期}举例：release/20250813 | 版本发布分支： 用于生产环境的发布。一般预发和生产均使用 release 分支。release 分支应从 master 分支中切出，并合并本期需要发布的各个 feature 或 fix 分支。 |
| 功能分支（临时：功能完成后可以选择性删除） | feature/{功能描述}举例：feature/changeci | 功能分支： 作为新需求/功能点开发时的分支。 |
| 修复分支（临时：修复完成后可以选择性删除） | fix/{修复描述} | 修复分支： 作为修复某个已知的 bug 的分支 |
| 紧急修复版本发布分支（临时：修复完成后可以选择性删除） | hotfix/{日期}举例： hotfix/2025-08-13 | 紧急修复分支： 用于线上 bugfix，后面需要合回 masterhotfix 分支应从 master 分支中切出，并合并当天需要发布的各个fix 分支。 |
| 开发分支（长期保留） | develop | 开发分支： 用于日常开发联调。 |
| 测试分支（长期保留） | test | 基于单测试环境前提，若实际项目中存在多测试环境，可不固定测试分支。 |
CI流程与版本号管理规范
CI流程概览
| 分支类型 | CI执行步骤 | 版本号规则 | 构建触发方式 |
|---|---|---|---|
| feature | ✅ Lint | 继承来源分支版本号 | 自动 |
| test | ✅ Lint + ✅ Build | 自动升级alpha版本（x.x.x-alpha.n） | 自动 |
| release | ✅ Lint + ❌ Build（需手动） | 次版本升级（x.x.0 → x.(x+1).0） | 合并后手动触发 |
| hotfix | ✅ Lint + ❌ Build（需手动） | 修订号升级（x.x.x → x.x.(x+1)） | 合并后手动触发 |
| major | ✅ Lint + ❌ Build（需手动） | 主版本升级（x.x.x → (x+1).0.0） | 合并后手动触发 |
版本号变更规则
预发布版本（test分支）
示例：
2.0.0 → 2.1.0-alpha.0
2.1.0-alpha.0 → 2.1.0-alpha.1
正式版本
| 分支类型 | 升级规则 | 示例 |
|---|---|---|
| release | 次版本号+1，修订号归零 | 2.0.4 → 2.1.0 |
| hotfix | 修订号+1 | 2.0.0 → 2.0.1 |
| major | 主版本号+1，其他归零 | 2.9.2 → 3.0.0 |
开发流程示例（以admin-components为例）
日常功能开发
- 创建分支
master(1.186.0)→feature/SC1-0813(保持1.186.0) - 测试阶段
test合并后自动升级：1.186.0-alpha.5 → 1.186.0-alpha.6 - 预发阶段
合并到release触发升级：1.186.0 → 1.187.0 - 生产发布
master最终版本：1.186.0 → 1.187.0
紧急修复流程
- 创建分支
master(1.186.0)→feature/SC1-0813(保持1.186.0) - 测试阶段
test合并后自动升级：1.186.0-alpha.5 → 1.186.0-alpha.6 - 生产修复
合并到hotfix触发升级：1.186.0 → 1.186.1
注意事项
⚠️ 版本冲突处理
当release分支合并出现冲突时，以master分支最新版本号为准
