Gitlab分支管理实践
- 整体流程图
- 分支规约
分支 | 分支命名 | 分支描述 |
---|---|---|
功能开发分支 | 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 |
- 常规流程
序号 | 阶段 | 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分支以及下一发布分支或开发分支(如果存在的话) |
- 热修复流程
序号 | 阶段 | 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分支以及下一发布分支或开发分支(如果存在的话) |
- 规约
5.1 Git 提交日志
-
Git提交必须编写commit message,否则不允许提交
-
Git提交日志必须符合【Git**** 日志规范】,否则不允许合并(直接打回Merge Request)
5.2 版本命名规范
-
版本号规范:采用GNU风格版本号,参考【版本命名规范】。第三位作为特性或修复版本,如1.0.1、1.0.2...
-
Tag命名规范:v{版本号},如:v1.0.1
5.3 分支合并规范
-
【禁止】将测试发布分支release_xxx和develop分支合并回feature分支
-
【推荐】每次发版后,及时将master合并回develop和feature分支
-
【推荐】feature分支合并到master并上线后即可删除
-
项目设置
6.1 角色分配
- 项目组长统一分配组员角色,指定Maintainer角色人员(测试人员全部设置为Maintainer)
6.2 分支保护
-
测试/发布分支(release_*):只允许项目maintainer合并和推送
-
生产分支(master):只允许项目maintainer合并和推送
6.3 Tag保护
- 只允许项目Maintainer能创建tag(进而触发生产环境审批/发布)
- 常见问题
1、如何解决多个功能,需要先后发布到UAT环境验收的问题?
方案:直接将当前迭代发布分支release_xxx,部署到UAT环境验收