优化前 git-flow 流程
之前团队的版本控制是基于 git-flow 的基础上进行简化, 同时也缺乏 review 的流程, 主要的流程及操作如下:
- 分支主要有 master, develop, release, bugfix, feature , 所有的正式版本 tag 基于 master 和 bugfix 分支上进行发布.
- 当规划新版本时, 在 develop 开发或基于 develop 拉 feature 分支进行开发并合并, 当规划版本功能开发完成时, 基于 develop 拉取 release 分支进行测试验证, 当验证完成后合并到 master 和 develop 上打好正式版本 tag 进行发布.
- 当发布的 tag 正式版本验证出现缺陷时, 会基于 tag 拉取新的 [ bugfix 共享分支 ] 进行所有缺陷的多人修复提交 ( 可能会存在新需求的增加 ), 后续再合并到 develop 和 master 分支.
- 如果 bugfix 修正的是最新的 tag 版本, 修正完成后合并到 master 并基于 master 打正式补丁 tag 发布版本, 再合并到 develop. 如果修正的是之前已发布的 tag 版本, 则基于 bugfix 分支打正式补丁 tag 发布, 再合并到 master 和 develop.
存在的问题
- 由于版本的周期比较长, 导致很多的缺陷及需求需要基于老的版本进行迭代, 影响版本的稳定性.
- bugfix 原本考虑作为一个短生命周期的分支, 后面实践时, 时常的需求及缺陷修复, 导致版本不稳定, 亦变成了一个长周期的分支;
- 之前老版本 tag 的 bugfix 分支版本发布不能基于 master, 只能基于 bugfix 分支, 流程不清晰;
- 老版本的 bugfix 分支代码合并到 develop 和 master 上, 合并后分支的代码 graph 历史图形混乱,追溯复杂. 可能新版本代码结构存在变更, 合并后存在冲突的问题, 导致 master 分支不稳定;
- 当最新的版本发布 release 测试版本时, 老版本的 bugfix 没有合并到 release 分支, 导致 release 分支测试不能覆盖;
- 代码提交没有 review 流程, 导致代码质量无法统一, 部分的代码质量及实现方案存在严重问题进行返工;
优化后 git-flow 分支
基于 git-flow 的基本流程, 增加基于 gitlab 的 merge request review 流程, 主要的流程及操作如下:
- 分支主要分为长周期分支, 中周期分支, 短周期分支
+------------+ +--------------+ +------------+
|short period| |medium period | |long period |
| | | | | |
+------------+ +--------------+ +------------+
| | |
.---+---. | .---+---.
( hotfix ) | ( master )
`---+---' | `---+---'
| .---+---. |
.---+---. ( release ) .---+---.
( bugfix ) `---+---' ( develop )
`---+---' | `---+---'
| | |
.---+---. | .---+---.
( feature ) | ( support )
`---+---' | `---+---'
| | |
| | |
长周期分支主要有 master, develop, support 分支, 中周期分支主要有 release 分支, 短周期分支主要有 feature, hotfix 分支;
- support 分支主要用于历史 tag 版本的后续修复分支(hotfix)发布, 功能类似于 master 分支(但 master 是基于最新代码打 tag ), 基于历史基础 tag 版本拉取命名为
support-基础通配版本号. 如有历史基础 tag 版本为 3.0.0, 拉取分支后为 support-3.0.x - hotfix 分支用于 tag 的紧急缺陷和需求分支, 基于历史最新 tag 拉取, 命名为
hotfix(-特征)-版本号, hotfix 的版本号需要往前递增. 如果要修复历史 3.0.0 tag 版本问题, 则命名为 hotfix(-特征)-3.0.1 - feature 用于开发版本需求, 主要用于功能需求的开发, 基于 develop 或 release 分支拉取, 命名为
feature-特征-版本号, feature 版本号不递增. 如现在 develop 版本为 3.1.0, 基于 develop 的新需求的版本为 feature-devXXX-3.1.0 ( 含义为基于develop 的某个功能分支 ) - bugfix 用于 develop 或 release 阶段版本的缺陷修复分支, 基于 develop 或 release 分支拉取, 命名为
bugfix-特征-版本号, bugfix 版本号不递增. 如现在 release 阶段版本为 3.1.0, 那么拉取的分支为 bugfix-relXXX-3.1.0 ( 含义为基于 release 的某个缺陷修复分支 ) - 长期分支不充许直接提交代码, 只能在 gitlab 网页端通过
merge request 申请合并, review 通过后进行合并代码. - 由于 release 分支是正式版本发布前的测试及缺陷修复分支, 所以属于中期分支, 主要用于缺陷的修正, 为保证代码质量, 也不允许直接提交, 也只能通过 merge request 申请合并.
优化后 git-flow 操作流程
先引用一张官方的操作流程图, 官方的流程图中是没有 support 的分支流程
以下说明一下基于 git-flow 的主要操作流程如下:
- 如果在 develop 上开发新功能, 首先基于 develop 分支创建本地 feature 分支增加功能, 分支功能完成后创建远端分支并提交, 在 gitlab 上申请代码合并 (merge request), 当其它人员 review 完成后合并到 develop 分支.
- 如果在 develop 上修复缺陷, 先基于 develop 分支创建本地 bugfix 分支修复缺陷, 分支功能完成后创建远端分支并提交, 在 gitlab 上申请代码合并 (merge request), 当其它人员 review 完成后合并到 develop 分支.
- 当规划功能在 develop 分支上完成后, 管理员基于 develop 分支创建远端 release 测试分支, 开发人员基于 release 分支创建本地 bugfix 分支修改缺陷, 本地分支缺陷修改完成后创建远端分支并提交, 进行 merge request 合并到 release 分支;
- 当 release 分支测试充分后, 管理员合并到 master 分支后发布正式 tag 版本, 同时合并到 develop 分支, 删除 release 分支.
- 当需要修复历史发布版本时, 先基于之前的 tag 创建 hotfix 分支, 次次版本需要递增. 修复完成后通过 merge request 合并到 support 分支发布正式补丁 tag 版本. 如果不存在 support 分支, 管理员需要基于已有基础 tag 创建 support 远端分支.
- hotfix 修复的缺陷, 不能直接合并到 master 和 develop, 如果当前还在 develop 上开发, cherry pick 到 develop 的 bugfix 分支, 后续通过 merge request 提交. 如果当前正处于 release 分支, cherry pick 到 release 的 bugfix 分支, 通过 merge request 提交;
- hotfix 分支如果是基于 master 最新的代码拉取 ( 即 tag 为最新代码 ), 修复完成后直接合并到 master 上发布 tag 版本, 但需要遵循上述规则合并到 develop.
- 每次 merge request 前都需要创建自己的远端分支;
- 当在 merge request 前需要编译临时版本让测试验证时, 直接基于自己的远端分支编译.