优化前 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-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 前须要编译长期版本让测试验证时, 间接基于本人的远端分支编译.
援用
- https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow