项目 git-flow 版本控制优化
优化前 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 流程, 主要的流程及操作如下:
分支主要分为长周期分支, 中周期分支, 短周期分支
长周期分支主要有 master, develop, support 分支, 中周期分支主要有 release 分支, 短周期分支主要有 feature, hotfix 分支;
support 分支主要用于历史 tag 版本的后续修复分支(hotfix)发布, 功能类似于 master 分支(但 master 是基于最新代码打 tag ), 基于历史基础 tag 版本拉取命名为
support-基础通配版本号
. 如有历史基础 tag 版本为 3.0.0, 拉取分支后为 support-3.0.xhotfix 分支用于 tag 的紧急缺陷和需求分支, 基于历史最新 tag 拉取, 命名为
hotfix(-特征)-版本号
, hotfix 的版本号需要往前递增. 如果要修复历史 3.0.0 tag 版本问题, 则命名为 hotfix(-特征)-3.0.1feature 用于开发版本需求, 主要用于功能需求的开发, 基于 develop 或 release 分支拉取, 命名为
feature-特征-版本号
, feature 版本号不递增. 如现在 develop 版本为 3.1.0, 基于 develop 的新需求的版本为 feature-devXXX-4.1.0 ( 含义为基于 develop 的某个功能分支 )bugfix 用于 develop 或 release 阶段版本的缺陷修复分支, 基于 develop 或 release 分支拉取, 命名为
bugfix-特征-版本号
, bugfix 版本号不递增. 如现在 release 阶段版本为 3.1.0, 那么拉取的分支为 bugfix-relXXX ( 含义为基于 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 提交;
每次 merge request 前都需要创建自己的远端分支;
当在 merge request 前需要编译临时版本让测试验证时, 直接基于自己的远端分支编译.
评论