5

我们正在采用新的分支策略来与敏捷合作，并使我们能够逐个特性地发布，因此我们有一个master分支和一个QA永久分支。每晚构建将基于QA和发布将来自master. 开发人员将为每个故事创建一个功能分支。所有功能分支都将被分支出来master，然后合并到QA测试中，然后将功能分支合并到master后续发布中。这很好，直到出现以下情况：

  • 开发人员 A（“Rod”）已经创建feature/RodsFeature、执行了一些工作并合并到QA（但还没有master）
  • 开发人员 B (“Jane”) 已经创建feature/JanesFeature、执行了一些工作，现在正试图合并到QA
  • Jane 的合并冲突现在正在发生，这是QA由 Rod 合并feature/RodsFeature

如果 Jane 绕过 QA 并合并feature/JanesFeature到master中，则不会出现冲突，因为feature/RodsFeature尚未在master. QA然而，出于显而易见的原因，简必须融入其中。为了解决冲突，她可以将 Rod 的更改拉入并将其集成到她的特性分支中，解决冲突然后执行合并 - 不良后果是，一旦她将她的特性分支合并到master其中，也会引入 Rod 的更改，这些更改是仍在等待质量检查测试。

所以 - 一种解决方法是直接在QA分支上解决冲突，让 Jane 的功能分支完好无损，以便以后合并到master. 但是，这违反了代码审查政策，因为合并应该得到同行的批准——通过这样做，她已经在本地合并QA并推送到远程，而没有任何拉取请求或同行审查。

在这种情况下，什么被认为是“最佳实践”？

4

2 回答 2

3

查看 Git 流程。它最接近你想要完成的事情。

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

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

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

也可以看看：

于 2016-08-25T14:40:08.560 回答
2

tl;dr：添加一个dev分支来执行特定“任务”分支的拉取请求以及代码审查的更改。

在我参与的一些团队项目中，还有一个dev分支可以在 Github 或某个存储库管理器上执行“拉取请求”，高级开发人员在那里查看已更改的内容，并查看该特定更改是否写得好等。

在像 Github 这样的在线 repo 托管环境中，他们有明确的 ui 展示与原始分支背靠背的更改等。在查看分支之后，高级开发人员然后将其移动到 Dev 分支，最终托管在 qa 环境中在冲刺结束时查看。

于 2016-08-25T14:39:59.290 回答