GIT分支管理规范
一、总体说明
- 版本管理工具：Git
- 开发阶段划分：开发 -> 测试 -> 预发布 -> 上线
- 环境说明：
- dev：开发环境
- test：测试环境
- release：预发布环境
- pro：生产环境
- 代码分支说明：
| 分支名称 | 分支用途 | 分支说明 | 分支示例 |
|---|---|---|---|
| master | 生产环境分支 | 与生产环境代码保持一致的代码基线，每次发布必须打tag | master |
| release-x.x.x | 提测分支 | 达到提测标准的版本代码，用于测试验证 | release-1.10.1 |
| dev-x.x.x | 版本开发分支 | 已确定版本的开发分支，用于功能开发 | dev-1.10.1 |
| dev-x.x.x-xx | 版本子分支 | 基于版本分支拆分的子分支，支持多需求并行开发 | dev-1.10.1-order |
| feature-{MMdd}-xx | 特性分支 | 用于迭代业务特性开发，特性上线后可删除 | feature-1226-invoice |
| hotfix-x.x.x | 热修复分支 | 用于修复生产环境紧急问题 | hotfix-1.10.101 |
二、分支关系及生命周期图
分支关系图展示了不同分支之间的合并流向和依赖关系
生命周期图展示了分支从创建到合并的完整流程
三、日常开发流程规范
开发任务管理
版本需求开发
- 版本子任务：开发负责人基于master创建版本开发分支（如dev-1.10.1），并根据功能模块拆分子分支（如dev-1.10.1-order）
- 小任务开发：直接在版本开发分支上进行开发
非版本需求开发
- 开发人员基于master创建特性分支，团队基于该分支进行开发，分支命名遵循feature-{MM-dd}-xx格式
提测流程
版本需求提测
- 版本子任务提测：开发人员将子分支（如dev-1.10.1-order）合并到开发分支（如dev-1.10.1），开发负责人将开发分支（dev-1.10.1）合并到提测分支（release-1.10.1）
- 小任务提测：开发负责人将开发分支（dev-1.10.1）合并到提测分支（release-1.10.1）
非版本需求提测
- 完成自测和联调后，将特性分支合并到开发分支并推送到远程（需开发负责人和项目负责人确认）
BUG修复流程
- 联调阶段BUG：在对应开发分支上修复
- 提测阶段BUG：在开发分支（dev-1.10.1）上进行修复，修复完成后重新提测
- 生产环境普通BUG：在最近提测的开发分支（dev-1.10.1）上修复
- 生产环境紧急BUG：从master拉取hotfix分支（如hotfix-1.10.101），修复完成后直接提测
发布流程
版本发布
- 测试通过后，开发负责人检查release分支，确保包含所有功能
- 发布完成后，将release分支合并到master分支，并打tag（每次发布必须打tag）
热修复发布
- 测试通过后，开发负责人检查hotfix分支，确保包含所有功能（注意master分支可能已更新）
- 发布完成后，将hotfix分支（如hotfix-1.10.101）合并到master分支和开发分支（dev-1.10.1），并打tag（每次发布必须打tag）
四、代码提交规范
提交前检查项
- 执行阿里代码规范检查
- 进行代码格式化
- 优化导入语句
- 执行代码分析
- 检查TODO注释
提交信息规范
提交信息必须以以下关键字开头：
- [add] 新增功能
- [modify] 修改功能
- [fix] 修复问题
- [delete] 删除功能
代码提交原则
- 保持提交粒度适中，确保功能完整性
- 提交前先拉取最新代码，避免不必要的合并冲突
五、分支合并规范
合并前准备
- 确保本地代码已提交或已暂存
- 在合并前执行
git pull更新本地分支 - 确保工作区干净，无未提交的更改
- 对于重要分支合并，建议基于源分支创建临时分支，在临时分支上进行合并验证，确认无误后再合并至目标分支
代码评审
- 创建Pull Request（PR），说明合并目的和改动点
- 指定相关人员进行代码评审
- 评审通过后执行合并操作
合并操作步骤
-
更新分支
- 切换到目标分支：
git checkout target-branch - 拉取最新代码：
git pull origin target-branch
- 切换到目标分支：
-
执行合并
- 使用IDE的"merge selected into current"功能或命令行
git merge source-branch - 发生冲突时使用
git merge --abort终止合并
- 使用IDE的"merge selected into current"功能或命令行
冲突处理规范
冲突预防
- 定期同步主分支代码，避免分支差异过大
- 合理拆分任务，避免多人修改同一文件
冲突解决
-
分析与处理
- 研发负责人和开发人员共同评估冲突
- 使用IDE工具逐个解决冲突文件
- 保留必要的代码注释和业务逻辑
-
验证与检查
- 确保所有冲突标记已清除
- 完整编译并运行测试
- 验证关键功能正常
特殊场景说明
- 复杂冲突建议使用
git rebase - 大规模合并需分批进行并专人审核
- 合并提交信息需包含来源分支、目的分支和任务编号
六、产品版本号规范
版本号格式
采用三段式版本号：d.d.d{hotfix}
版本号说明
- 第一段：产品重大版本升级
- 第二段：产品中等版本升级
- 第三段：产品日常版本升级（3位数，后两位用于BUG修复）
版本号示例
当前版本：1.10.1
- 热修复版本：1.10.101
- 热修复分支：hotfix-1.10.101
当前版本：1.10.101
- 热修复版本：1.10.102
- 热修复分支：hotfix-1.10.102
