Gitlab分支管理实践

Posted on 2022-08-15 16:58  得失乐与悲与梦儿  阅读(482)  评论(0)    收藏  举报

Gitlab分支管理实践

  1. 整体流程图

  1. 分支规约
分支 分支命名 分支描述
功能开发分支 origin/feature_$ 1. 用于承载具体的功能开发，基于最新的master分支检出
1. 命名规范：feature_{日期}_{功能}。如：feature_20220809_login
开发集成分支 origin/develop 1. 在开发环境集成各个功能分支，用于开发自测或联调
测试/发布集成分支 origin/release_ 1. 在测试环境集成各个功能分支，用于测试人员测试
2. UAT环境验收（部分功能）：如果需要提前验收部分功能，则部署到UAT环境验收
3. 可能同时存在多个（即n * release），支持多版本并行测试（需要多套测试环境）
4. 命名规范：release_{发布日期}。如：release_20220801、release_20220801_1（部分功能无法上线，则重新检出）
热修复分支 origin/hotfix_$ 1. 用于修复生产环境Bug，基于master分支或指定Tag版本检出
2. 命名规范：hotfix_{日期}_{修复功能}。如：hotfix_20220801_loginBug
主干分支 origin/master 1. master分支代表项目的基线，不允许直接修改
2. UAT环境验收（全部功能）：全部功能测试通过后，将release_xxx合并到master分支，部署master到UAT环境验收
3. 生产环境发布：基于当前master分支打tag，审批发布上线
4. Tag命名规范：v{版本号}。如：v1.0.1
  1. 常规流程
序号 阶段 Gitlab 角色 组织角色 操作 / 事项
1 迭代开始 Maintainer 开发组长/SA 基于最新master检出新的发布分支：release_xxx（可以多个）
Developers 开发人员 基于最新master检出新的开发分支：feature_xxx（多人可共用一个）
2 开发阶段 Developers 开发人员 在feature分支开发，开发完成后，将feature分支合并到develop分支，部署develop到开发环境自测或联调
3 提测阶段 Developers 开发人员 在Gitlab发起Merge Request，合并到release_xxx分支
4 代码审查&合并 Maintainer 开发组长/SA 完成Code Review并合并到release_xxx分支
5 测试阶段 Maintainer 测试人员 部署release_xxx分支到测试环境测试（支持多版本并行测试，需要多套测试环境）
6 UAT验收 Maintainer 开发组长/SA 将release_xxx合并到master，部署master到UAT环境
Other 产品或业务 产品或业务在UAT环境验收
7 发布上线 Maintainer 测试人员 基于当前master分支打tag，发起生产环境部署审批，完成发布上线
8 收尾阶段 Maintainer 开发组长/SA 将master分支合并到develop分支以及下一发布分支或开发分支（如果存在的话）
  1. 热修复流程
序号 阶段 Gitlab角色 组织角色 操作 / 事项
1 开发修复 Developers 开发人员 基于当前master检出热修复分支hotfix_xxx，修复后合并到develop分支，部署develop到开发环境自测或联调
2 开发提测 Developers 开发人员 通知测试人员部署hotfix_xxx分支测试
3 测试阶段 Maintainer 测试人员 部署hotfix_xxx分支到测试环境测试
4 合并请求 Developers 开发人员 在Gitlab发起Merge Request，合并到master分支
5 代码审查&合并 Maintainer 开发组长/SA 完成Code Review并合并到master分支
6 UAT验收 Maintainer 开发组长/SA 部署master分支到UAT环境验收
Other 产品或业务 产品或业务在UAT环境验收
7 发布上线 Maintainer 测试人员 基于当前master分支打tag，发起生产环境部署审批，完成发布上线
8 收尾阶段 Maintainer 开发组长/SA 将master分支合并到develop分支以及下一发布分支或开发分支（如果存在的话）
  1. 规约

5.1 Git 提交日志

  1. Git提交必须编写commit message，否则不允许提交

  2. Git提交日志必须符合【Git**** 日志规范】，否则不允许合并（直接打回Merge Request）

5.2 版本命名规范

  1. 版本号规范：采用GNU风格版本号，参考【版本命名规范】。第三位作为特性或修复版本，如1.0.1、1.0.2...

  2. Tag命名规范：v{版本号}，如：v1.0.1

5.3 分支合并规范

  1. 【禁止】将测试发布分支release_xxx和develop分支合并回feature分支

  2. 【推荐】每次发版后，及时将master合并回develop和feature分支

  3. 【推荐】feature分支合并到master并上线后即可删除

  4. 项目设置

6.1 角色分配

  1. 项目组长统一分配组员角色，指定Maintainer角色人员（测试人员全部设置为Maintainer）

6.2 分支保护

  1. 测试/发布分支（release_*）：只允许项目maintainer合并和推送

  2. 生产分支（master）：只允许项目maintainer合并和推送

6.3 Tag保护

  1. 只允许项目Maintainer能创建tag（进而触发生产环境审批/发布）

  1. 常见问题

1、如何解决多个功能，需要先后发布到UAT环境验收的问题？

方案：直接将当前迭代发布分支release_xxx，部署到UAT环境验收