敏捷分支工作流的 Git merge 策略

标签 git agile branching-and-merging branching-strategy

我们正在采用新的分支策略来与敏捷合作,并使我们能够逐个特性地发布,因此我们有一个 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/RodsFeatureQA 带来的变化引起的

如果 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/

相关文章:

agile - 如何维护有关敏捷环境中当前功能状态的最新文档

project-management - 游戏开发中的 Scrum 项目管理有什么好的和简单的工具?

git - Git checkout 双破折号的含义

git - 将开发分支 merge 到主分支的最佳实践是什么

agile - 连续进行 Scrum 冲刺会导致倦怠吗?

git - 如何理解来自Git的SVN

git - 我的 git 分支在 Sourcetree 中显示 'origin/master' 和 'origin/HEAD',我不知道如何 merge 两者

java - 从 jgit 中的提交获取存储库

git - 将分支推送到私有(private)仓库

git - 为什么在这种情况下我在 Git 中的本地更改会被 checkout 覆盖?