一.gitflow工作流

说明：

• 主分支：master，稳定版本代码分支，对外可以随时编译发布的分支，不允许直接Push代码，只能请求合并（pull request），且只接受hotfix、release分支的代码合并。gitlab上做限制。
• 热修复分支：hotfix，针对现场紧急问题、bug修复的代码分支，修复完后合并到主分支、开发分支 bug修复用hotfix分支测试验证 发布 命名规则：hotfix_版本号_20220811
• 发版分支：release，版本发布分支，用于迭代版本发布。迭代完成后，合并dev代码到release，在release分支上编译发布版本，以及修改bug（定时同步bug修改到dev分支）。测试完成后此版本可以作为发版使用，然后把稳定的代码merge到master分支，并打上版本标签。
  release 多版本管理命名规则：release+“_”+功能说明+“_”+日期。示例：release_cashwithdrawal_20220811 , release_fund_20220801
• 开发环境分支：dev，开发版本分支，针对迭代任务开发的分支，日常开发原则上都在此分支上面，迭代完成后合并到release分支。
  如果有多环境并行部署 dev 命名规则：dev+“_”+功能说明+“_”+日期。示例：dev_cashwithdrawal_20220706 , dev_fund_20220725
• 研发开发分支：feature-***，开发人员可以针对模块自己创建本地分支，开发完成后合并到dev开发分支，然后删除本地分支(多个人共享开发 可以推送feature 到git) 命名规则：featre+“_”+功能说明+“_”+日期。
• dev 每次迭代版本 每个pom版本升级异常 pom 版本名称规则与tapd或者代码版本保持一致，deploy SNAPSHOT 包；测试通过后升级release分支pom 版本为RELEASE包

二.常规需求迭代流程

备注：

• 绿色部分是迭代任务一 蓝色部分是迭代任务二；迭代任务一发版完合并代码到master分支 和 迭代二开发环境迭代分支

三.生产bug修复流程

备注：

• 橙色部分是bug修复迭代任务 绿色部分是当前迭代任务；hotfix 分支发版验证通过后，合并代码到master和当前迭代任务的dev分支