gitflow 在实践中的一些疑问

[simonlu9]

• 假设以下场景，A 和 B 都开发一个功能，各自从 dev 切一个 feature 出来开发，然后开发完提测的话先合并到 dev，然后就到 release 提测改 bug,但是现在有个问题，a 和 b 都差不多时间开发完，然后都合并到 dev 分支了，-。
• 这时候，a 的功能测试没问题，b 的测试有问题，这时候想只上 a 的功能，排除 b，但是 dev 已经包含了 a 和 b 的代码，这时候一般要怎么办？

[simonlu9]

@KuroNekoFan @beidounanxizi @boris93 @chenluo0429 @f6x @guyeu @hantsy @jerryzhou343 @joesonw @linxb
@hantsy，我总结了，麻烦看看付加的信息，看看有没有什么问题

[hantsy]

CI 是保证了在多人开发环境中如果有人代码 Break 了业务逻辑等，回归测试中立即报告问题。

你这流程没法看，复杂的程序，国际化多人开发的项目参与过很多，没用过你这种复杂的 Git 流程。

一句话，不写测试的 CI, CD 没太大意义。你这种加一个 CI，只是加快了相互扯皮的频率。

[f6x]

你补充的方法,完全和 gitflow 背道而驰了.

没有正确的流程,只有适合的流程.
看你这么重视 feature 隔离, 可以直接用 aoneflow 吧.

[jerryzhou343]

@simonlu9 每个分支都有自己的角色（责任）和生命周期，所以不用纠结你的流程一定要遵循 gitflow，你可以定义自己的 xxx 流程；
回复第一点：这个描述下，这个流程中有 feature , release, test, master，dev ; 在这个模式下，如果团队对提交干净整洁度没有洁癖的话，test，dev 分支就没啥用了。到测试时间点的时候，拉 release，然后合并测试，测试 ok 直接上 release ；如果你们有提交整洁度要求，那可以用 test-xxx 这样的分支来做初次汇聚，测试完成； feature 提交做 rebase，然后再拉 release 合并发布；
回复第二点：基于上一次发布拉出 fix-xxx 分支，修复完成；看发布计划，如果是紧急重要，这个 bug fix 提前单独 release 出去；如果不紧急重要，就跟着发布计划，合并到 test 测试，跟着需求上线；
回复第三点：feature 分支的内容并不一定需要马上合并到 test 的，也许只是开发人员同步代码的时候一次提交，并不想合并，所以这里不建议做自动化；
回复第四点： 分支存在的理由是它有自己的角色和职责；先有需求，才有了对应的分支，不要陷入固定的思维，可以问下自己，gitflow 为什么有 dev 分支；
回复第五点：公共部分代码是不是可以认为是 featureC 呢；如果没有公共部分，featureA，featureB 就无法进行下去；那么可以先做好公共部分再启动 featureA，featureB 的开发；或者三个分支独立，featureA，featureB 先依赖一个接口，然后在测试的是汇聚；或者 featureA,featureB 合并为一个需求,一起开发；（公共部分代码在这个情况下也是不稳定的，featureA,featureB 贸然合入，并不一定是好的选择)