4

在编写新故事时，我们在我的公司使用以下 git 工作流程：

  1. 从 master 创建一个主题分支（生产/稳定）
  2. 根据需要创建尽可能多的提交以实现功能。
  3. 对该主题分支执行 git merge --squash 到qa分支。
  4. 质量检查人员审查。
  5. 如果好，代码合并到ua分支。如果用户验收团队祝福它，它就会被合并到 master 并最终部署。
  6. 如果审核失败，开发人员需要修复。基本上在第 2 步重新启动该过程。

注意：从点代码合并到 qa 分支到 qa 拒绝/接受它的时间最长可能需要两周时间。

如果没有问题，那么代码最终会成为 master。但是，我正在寻求 QA 发现问题并且您必须修复它时的最佳实践。我想要的是最终得到一个看起来尽可能“原始”的 qa 分支。

如我所见，以下是选项：

  1. 恢复 qa 分支中的原始压缩提交，从 qa 重新设置主题分支，修复主题分支中的代码，再次将其合并到 qa 中。问题：留下 icky revert 提交。
  2. 删除现有的主题分支，从 qa 分支重新创建它，创建一个简单的提交来修复问题，合并回 qa。问题：将功能的代码更改分布在时间和地点不同的提交中。
  3. 取消对 qa 的压缩合并，将单个提交从 qa 重新定位到现有主题分支，用另一个提交修复，合并到 qa。问题：多次提交使得在移动到 ua 分支然后到 master 时很难跟踪更改。

问题：当合并代码可能需要修复时，是否有通过多个长期存在的分支（master -> topic -> qa -> ua -> master）移动单个功能的多个提交的最佳实践？

4

1 回答 1

1

根据经验，保留一个分支来修复在 qa 或 ua 或 master 中发现的东西的想法并不顺利，因为它人为地链接在一起（在同一个分支内）最终导致完全不同的开发工作。
您在 ' ' 之后修复的错误qa通常比在 ' ua' 或 ' master' 中发现的错误更直接（因为在开发生命周期中发现得更早）。

所以我会选择 2.，但没有“删除主题分支”部分，只有“创建新主题分支”用于您需要在开发周期中进行的特定修复/演变。

于 2010-09-07T21:38:18.707 回答