GitFlow分支策略并行发布处理问题咨询（Bitbucket环境）

一、紧急处理：创建仅含f_1、f_2的release_f分支 #

目前develop分支已经混入未准备好的n_1提交，有两种方式快速生成纯净的release_f分支：

方法1：Cherry-pick目标提交 #

1. 用git log找到0.0.1的提交哈希，基于它创建release_f分支：

   git checkout -b release_f <0.0.1的哈希值>
   

2. 同样通过git log获取f_1、f_2的提交哈希，依次cherry-pick到release_f分支：

   git cherry-pick <f_1的哈希值>
   git cherry-pick <f_2的哈希值>
   

3. 完成后release_f就只包含f_1、f_2的代码，后续正常走GitFlow发布流程即可。

方法2：Revert掉n_1再分支 #

1. 切换到develop分支，找到n_1的提交哈希，执行revert撤销它的改动：

   git checkout develop
   git revert <n_1的哈希值>
   

2. 基于当前的develop创建release_f分支：

   git checkout -b release_f
   

3. 如果之后team_2要继续开发n_1，回到develop分支再revert刚才的撤销操作即可：

   git checkout develop
   git revert <刚才revert操作产生的提交哈希>
   

二、长期优化：适配并行版本的分支策略 #

GitFlow默认是单版本迭代模式，多团队并行不同版本的话，推荐两种调整方案：

方案1：多Develop分支变种 #

• 为每个待发布版本单独维护develop分支，比如develop-f和develop-n
• 各团队的特性分支基于对应版本的develop创建：f_1、f_2从develop-f拉分支，n_1从develop-n拉分支
• 发布时从对应版本的develop创建release分支，测试通过后合并到master和自身的develop分支；如果有公共需求，把公共提交cherry-pick到另一个develop分支即可。

方案2：主干开发+特性开关 #

• 所有开发分支直接合并到主干（master/main），但给每个特性加上可配置的开关
• 开发阶段特性开关默认关闭，仅在测试环境开启验证
• 当某个版本的所有特性都准备好发布时，打开对应开关打包发布；未就绪的特性保持关闭，不会进入生产环境
• 这种方式不用维护多分支，能有效避免合并冲突，并行开发更灵活。

内容的提问来源于stack exchange，提问作者Gaurang Shah