13

我无法理解如何处理以下情况：

  1. 功能 A 承诺master为 commit A。
  2. 我们已准备好发布v1.0.0，因此我们将提交标记A为v1.0.0，并从中创建一个发布分支rel-1.0.x用于 QA。
  3. 功能 B 承诺master为 commit B。
  4. QA 批准v1.0.0，我们部署和删除rel-1.0.x分支。
  5. 我们已准备好发布v2.0.0，因此我们将提交标记B为并从中v2.0.0创建一个分支用于 QA。rel-2.0.x
  6. 在生产中发现了一个错误 ( v1.0.0)，必须立即修复和部署。

在这一点上，我不确定我们应该如何处理。如果错误在主干中，我们可以从主干创建一个修补程序分支，修复错误并合并到主干中。然后，从创建一个rel-1.0.1分支v1.0.0，从主干中挑选修复，将其标记为v1.0.1并部署。

现在我觉得奇怪的是，v1.0.1提交不是原样的，master因为它是从分支中挑选出来并在分支master中标记的。rel-1.0.1此外，如果还需要修复，rel-2.0.x那么我们应该如何处理呢？我们是否应该再次从主干中挑选错误修复并将其标记为不同的版本，例如v2.0.1？

这是我将要执行上述操作的那种图表（请注意，v1.1 代表上述文本的 2.0 版本，并且它是Second feature A fix在准备v1.1发布时发生的。）：

在此处输入图像描述

4

1 回答 1

0

回到这个问题，我的担忧似乎没有成立，版本控制/标记方法以及上述问题中描述的工作流程是可以接受的，并且在实践中工作得很好。

不过，我面临的一个挑战是，当 master 与生产中的内容越来越偏离时。发生这种情况的原因有很多，例如 master 中的提交理论上已经准备好发布，但不知何故没有投入生产。我处理这个问题的方法是在生产中不断地重新处理提交树，以便分歧保持在最前面。

于 2020-02-20T15:21:34.783 回答