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