项目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 分支, 流程不清晰;