分子

@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 贸然合入，并不一定是好的选择)

@simonlu9 接上条回复。每个分支的职责其实需要根据你们的开发流程来定的；如果你们走的瀑布模式的流程；在 dev 分支修复 bug 是没问题的；如果你们走的敏捷迭代模式，最好不好在 dev 上修 bug ；因为在 sprint 中，某个 feature 可能赶不上时间点；所以建议的是不要在 dev 上修 bug ；不然 cherry-pick 有时候也挺麻烦的； feature 分支提交记录多用 rebase，这样可以让提交记录清晰，并且不会太多；

@simonlu9 每个分支都有自己的角色（责任）和生命周期； dev 分支作为 feature 的汇聚分支，合并其他 feature 就是其责任，所以 dev 不存在污染一说； feature 有 bug，在对应 feature 修改，然后再合并到 dev ；如果有 bug 直接在 dev 修，那才是污染 dev 分支了，让 dev 承担了开发的职责；

修正下命令:cherry-pick