gitflow在实践中的一些疑问

• 假设以下场景，A 和 B 都开发一个功能，各自从 dev 切一个 feature 出来开发，然后开发完提测的话先合并到 dev，然后就到 release 提测改 bug,但是现在有个问题，a 和 b 都差不多时间开发完，然后都合并到 dev 分支了，-。


• 这时候，a 的功能测试没问题，b 的测试有问题，这时候想只上 a 的功能，排除 b，但是 dev 已经包含了 a 和 b 的代码，这时候一般要怎么办？

第 1 条附言  ·  106 天前

谢谢大家回复，总结如下，不能完全用 gitflow 这个流程，我也看过 aoneflow 流程，也是有改良的，我觉得小型团队可以这样做
- 1 新功能开发还是要用 feature 开发，开发完并不能马上合并 dev,提测的话直接合并到 test 分支，多个 feature 就一起合并到 test，让测试验证，验证有 bug,然后自己再各自的 feature 修好，然后再合并到 test 分支（基于 master ），test 分支没问题直接上正式 en，正式没问题的话再把 feature 分支合并到 dev 和 master，保证 feature 是干净的，不参合任何代码，如果 a 和 b 到时候有谁上不了，直接用 master 分支拉一个副本出来然后合并到 feature 分支发版

- 2 .如果这时候正式环境有 Bug,而你又再 feature 上，按照 gitflow 流程到 master 拉个分支补丁处理，（这时候又个疑问，提测是否合到 test 分支上还是拉上一次的 release 分支）然后处理完在合并到 dev 和 mater

- 3.test 分支最好有一个自动检查，当 feature 分支 push 变更时，能够自动重新合并分支（ master+featrueA+featureB ）,部署就变得很简单

- 4.dev 分支好像变得没什么用

- 5. 还有一种情况就是，featureA 和 featureB 开发的时候，有一些公共代码要开发，这时候怎么办，因为 featureA 和 B 到要用到，我想到的时直接到 dev 提交这些公共的部分，然后 featureA，B 分别合并 dev 分支的公共代码，然后再把 dev 分支关上，不允许任何人提交，这样最保险

- 6.我能想象开发遇到的情况都说了，不知道，我说的对不对，大家给点意见

我司是 feature 直接合到 master，CI/CD 检测到 master 有更新就自动部署到 dev 环境，并打 git tag
生产部署取 git tag 对应的代码版本

对于你这种情况，我们会选择都不上线，等 bug 修好再一起上。很紧急的上线的话，那么就先把 b 的代码改回去，这就相当于只上线了 a 。

话说你们应该也有个 release 用的分支吧，把 a 相关的提交 cherry-pick 到 release 用的分支，就可以把 b 撇出去了