我们正在采用新的分支策略来使用Agile并使我们能够逐个功能发布功能，因此我们拥有master分支和QA分支作为永久分支机构。每夜构建将基于QA，版本将来自master。开发人员将为每个故事创建一个功能分支。所有要素分支都将分支master，然后合并到QA进行测试，然后将要素分支合并到master以供后续发布。这很好，直到以下情况：
feature/RodsFeature，执行了一些工作并合并到QA（但还没有master）feature/JanesFeature，执行了一些工作，现在正尝试合并到QA QA feature/RodsFeature的更改引起的
如果Jane要绕过质量检查并将feature/JanesFeature合并到master，那么feature/RodsFeature尚未出现master，就不会发生冲突。但是，由于显而易见的原因，Jane必须合并到QA。为了解决冲突，她可以将Rod的更改整合到她的功能分支中，解决冲突，然后执行合并 - 一旦她将她的功能分支合并到master中，就会产生不良后果它还将介绍Rod的变化，这些变化仍在等待QA测试。
所以 - 解决方法是直接在QA分支上解决冲突，保留Jane的功能分支，以便以后合并到master。但是，这会破坏代码审查策略，因为合并应该由对等方批准 - 通过这样做，她已在本地合并到QA并推送到远程而没有任何拉取请求或同行评审。
什么是最佳实践＆＃39;在这种情况下？
答案 0 :(得分：3)
查看Git Flow。它最接近你想要完成的任务。
开发人员将其功能分支从qa分支（在Git Flow中称为develop）分支出来。完成他们的功能（定期获取最新的QA状态）并尽可能合并回develop（功能完成或处于稳定状态或关闭）。
您作为qa分支运行的内容可能是Gitflow中的release分支。
对master的任何更改都会立即合并回develop。
另见：
答案 1 :(得分：2)
tl; dr ：添加dev分支来执行特定“任务”的拉取请求。分支与代码审查的更改。
在我参与过的一些团队项目中，还有一个dev分支机构可以做＆＃34;拉取请求＆＃34;在Github或某个存储库管理器上，高级开发人员查看已更改的内容并查看该特定更改是否写得很好等。
在像Github这样的在线repo主机环境中，他们有明确的ui与原始分支等一起展示变化。在查看分支后，高级开发人员将其移动到Dev分支中，最终被托管在qa中在冲刺结束时要查看的环境。