在前文《分支模型：Git Flow模型》详细介绍了经典Git Flow模型和使用案例，这里简单地回顾一下这个案例：
- 开发新功能order ：从develop分支上创建出feature/order分支，在开发完成后合并回develop分支。
- 开发新功能payment ：从develop分支上创建出feature/payment分支，在开发完成后合并回develop分支。
- 测试 ：从develop分支上创建出release/1.0.0发布分支，在这个发布分支上进行测试、修复缺陷等工作。
- 发布 ：测试通过后，将release/1.0.0分支合并到main分支，并打上tag v1.0.0，发布main分支代码到生产环境。
- 同步到develop分支 ：发布到生产环境后，需要将main分支代码合并到develop分支，以确保develop上包含有测试阶段修复缺陷的代码。
- 修复生产缺陷 ：发布到生产环境后如果出现了缺陷，则从main分支的tag v1.0.0处创建hotfix/v1.0.1分支，在这个分支上修复缺陷，并合并回main分支，打上tag v1.0.1，发布main分支代码到生产环境。同时，需要将main分支代码合并到develop分支，以确保develop上包含有hotfix修复缺陷的代码。
如果产品经理期望在当前迭代仅发布新功能feature/order，在下个迭代才发布新功能feature/payment，即payment虽然在当前迭代时间窗口内开发，但不需要发布，这时候怎么办呢？有读者可能会想到，“直接在release分支上回退feature/payment代码不就可以了吗？” 是的，这个方案的确可以解决发布部分新特性的问题，但不要忘记了，release分支上回退feature/payment的commit提交最终也会被合并回develop分支，但这意味着develop上的feature/payment提交会丢失，这将会影响到下一迭代开发（feature/payment可能需要在下一个迭代上线）。那还有其他办法吗？今天介绍流行的Git Flow变种方案，解决发布部分新特性问题。
解决方案
导致release分支包含了所有新特性的功能的根本原因在于 – release分支是从develop分支创建出来的。那么，解决方案就是：只要让release分支不从develop分支上创建，而是从main分支上创建release分支，就可以规避这个问题。紧接着，挑选需要发布的新功能feature分支，将其合并到release分支即可。 这个变种方案可以让release分支变得更加灵活，允许让团队自由选择需要发布的新特性。 另一个好处是，允许团队严格控制开发过程和测试过程，例如：让开发人员对develop分支负责，让测试人员对release分支负责。进入测试阶段时，开发人员发起feature分支到release分支的MR合并请求，测试人员审核MR合并请求。测试过程中如果发现了缺陷，则可以让开发人员从release分支创建出临时的修复分支，发起MR合并请求，测试人员审核MR合并请求。 这个变种方案的缺点是，如果新功能分支数量非常多，并且大部分新功能都需要上线时，会加重团队的负担。想象一下，有100个新功能分支，全部都需要发布，或者99个需要发布。
示例
让我们应用这个解决方案到之前的案例上：
- 开发新功能order ：从develop分支上创建出feature/order分支，在开发完成后合并回develop分支。
- 开发新功能payment ：从develop分支上创建出feature/payment分支，在开发完成后合并回develop分支。
- 测试 ：从main分支上创建出release/1.0.0发布分支，合并feature/order分支代码到release/1.0.0分支上，在这个发布分支上进行测试、修复缺陷等工作。
- 发布 ：测试通过后，将release/1.0.0分支合并到main分支，并打上tag v1.0.0，发布main分支代码到生产环境。
- 同步到develop分支 ：发布到生产环境后，需要将main分支代码合并到develop分支，以确保develop上包含有测试阶段修复缺陷的代码。
- 修复生产缺陷 ：发布到生产环境后如果出现了缺陷，则从main分支的tag v1.0.0处创建hotfix/v1.0.1分支，在这个分支上修复缺陷，并合并回main分支，打上tag v1.0.1，发布main分支代码到生产环境。同时，需要将main分支代码合并到develop分支，以确保develop上包含有hotfix修复缺陷的代码。
可以看到，变化之处在第3步测试， release分支是从main分支上创建出来的，而不是develop。同时，挑选了需要发布的新功能分支，将其合并到release分支上。
总结
本文介绍的Git Flow变种方案，可以让release分支变得更加灵活，允许让团队自由选择需要发布的新特性，团队也可以严格控制开发过程和测试过程。但同时需要注意到这个变种方案会给开发团队增加额外的分支合并工作量。