git工作流的问题
一般正常的工作流程图如下
一般正常的git工作流是开发接到A需求,准备投入开发
1.第一步，先从develop分支拉取feature/A分支
2.第二步,开发完成合并到develop分支上,
3.第三布,把developer分支合并到release/A分支上,此时release/A分支只能是修复bug,测试完成
4.第四步,把release/A分支合并到master分支和develop分支上
5.接到B需求,重复上述步骤
问题一
若接到A开发和B开发同时接到A需求和B需求
A和B同时并行开发,此时会有feature/A分支,feature/B分支
若A已经走到release/A测试流程,此时B开发完成,是否需要把release/A合并到develop分支,在把develop分支合并到feature/B分支,在把feature/B分支合并到developer,则feature分支则会同时存在A需求和B需求的代码
问题二
A,B需求并行开发,并行测试
在release分支上,会同时存在A、B两个需求,
情况一，A需求测试完成,准备上线,B未测试完成,但release合并到master会把B需求的代码带上线
情况二，A,B需求都测试完成,但上头领导说只上线A需求,后续有新的C需求,等C需求上线完成在上线B需求
一般这种并行开发,并行测试但上线时间点不一样是怎么处理的
回答
标准的git flow适合有明确版本滚动周期的团队使用，小团队以及追求敏捷的团队都不适合，这就涉及到问题一，功能测试不进release，feature完成也不会直接合并develop，必须项目进度进入了release阶段，确定发布的feature全部合并到develop并签出release，开始在release上进行回归啊，冒烟啊修复bug啊，完成后release合并master及develop，而且同一时间只能有一个release分支，不然release的意义就不大了. 问题二，一种是技术方案，即所有的功能都要有开关控制，上不上线就是一个配置问题. 另一种就是版本控制的方案，已经进入release了，但又不想发布的功能，操作的前提是从feature开始，这个功能的所有代码提交，bug修复都是独立提交，已经逻辑上不要被其它功能依赖，这样的话不会只需要把release里的bug修复遴选到你之前的feature上去，并在release里revert掉这个功能的所有提交，release就可以发布了。 看你描述的问题，我建议不要完全使用git flow，
以上是 git工作流的问题 的全部内容， 来源链接： utcz.com/a/64335.html
