Git Agile Branching工作流程的合并策略

Question

我们正在采用一种新的分支策略来与Agile合作,并使我们能够逐个功能发布,我们有一个master分支和一个QA分支作为永久分支.每晚构建将基于QA和发布将来自master.开发人员将为每个故事创建一个功能分支.所有要素分支都要分支master,然后合并到QA测试中,然后将要素分支合并到master后续版本中.这很好,直到以下场景:

• 开发人员A("Rod")创建feature/RodsFeature,执行了一些工作并合并到QA(但还没有master)
• 开发人员B("简")创建feature/JanesFeature,执行了一些工作,现在正在尝试合并QA
• Jane现在正在发生合并冲突,这是QA由Rod合并引入的变化引起的feature/RodsFeature

如果Jane要绕过QA并合并feature/JanesFeature进去master,那么就没有冲突,因为feature/RodsFeature还没有master.但是,Jane必须合并QA,原因很明显.为了解决冲突,她可以将Rod的变化拉入并整合到她的特征分支中,解决冲突然后进行合并 - 一旦她将她的特征分支合并到master其中,会产生不良后果,也会引入Rod的变化.还在等待QA测试.

所以 - 解决方法是直接解决QA分支上的冲突,保留Jane的功能分支,以便以后合并master.但是,这会破坏代码审查策略,因为合并应该由对等方批准 - 通过这样做,她已合并到QA本地并推送到远程而没有任何拉取请求或同行评审.

在这种情况下,什么被视为"最佳做法"？

Answer 1

查看 Git 流程。它最接近您想要实现的目标。

开发人员将他们的功能分支从分支上分支出来qa（develop在 Git Flow 中称为）。完成他们的功能（定期获取 QA 的最新状态）并develop尽可能合并回（功能已完成或处于稳定状态或已关闭）。

您作为分支运行的qa可能是releaseGitflow 中的分支。

对 master 的任何更改都会立即合并回develop.

也可以看看：

• https://www.atlassian.com/git/tutorials/comparing-workflows/