我们正在采用新的分支策略来与敏捷合作,并使我们能够逐个特性地发布,因此我们有一个 master
分支和一个 QA
分支为永久分支。每晚构建将基于 QA
,发布将来自 master
。开发人员将为每个故事创建一个功能分支。所有特性分支都从master
分支出来,然后 merge 到QA
中进行测试,然后将特性分支 merge 到master
中进行测试随后发布。这很好,直到出现以下情况:
- 开发人员 A(“Rod”)创建了
feature/RodsFeature
,进行了一些工作并 merge 到QA
(但还不是master
) - 开发人员 B(“Jane”)创建了
feature/JanesFeature
,进行了一些工作,现在正尝试 merge 到QA
- 现在 Jane 发生了 merge 冲突,这是由于 Rod merge
feature/RodsFeature
给QA
带来的变化引起的
如果 Jane 绕过 QA 并将 feature/JanesFeature
merge 到 master
中,就不会有冲突,因为 feature/RodsFeature
不是还在 master
中。但是,出于显而易见的原因,Jane 必须 merge 到 QA
。为了解决冲突,她可以 pull Rod 的更改并将其集成到她的功能分支中,解决冲突,然后执行 merge - 一旦她将她的功能分支 merge 到 master
中,就会产生不良后果'还将介绍 Rod 的更改,这些更改仍在等待 QA 测试。
因此 - 一种变通方法是直接在 QA
分支上解决冲突,让 Jane 的功能分支完好无损,以便稍后 merge 到 master
中。然而,这违反了代码审查政策,因为 merge 应该得到同行的批准 - 通过这样做,她已经在本地 merge 到 QA
并推送到远程,而没有任何 pull 请求或同行审查。
在这种情况下,什么会被视为“最佳实践”?
最佳答案
查看 Git Flow。它最接近您要实现的目标。
开发人员会将他们的功能分支从 qa
分支中分支出来(在 Git Flow 中称为 develop
)。完成他们的功能(定期获取 QA 的最新状态)并尽可能 merge 回 develop
(功能已完成或处于稳定状态或已关闭)。
您作为 qa
分支运行的可能是 Gitflow 中的 release
分支。
对 master 的任何更改都会立即 merge 回 develop
。
另见:
关于敏捷分支工作流的 Git merge 策略,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/39147873/