git - 基于主干的开发版本和修补程序问题

Question

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

特性 A 致力于 master作为提交 A .

我们准备发布 v1.0.0所以我们标记提交 A如 v1.0.0我们创建了一个发布分支 rel-1.0.x来自它的质量保证。

功能 B 致力于 master作为提交 B .

QA 批准 v1.0.0 ，我们部署和删除 rel-1.0.x分支。

我们准备发布 v2.0.0所以我们标记提交 B如 v2.0.0并创建一个 rel-2.0.x从它分支到 QA。

在生产中发现了一个错误 ( v1.0.0 )，必须立即修复和部署。

在这一点上，我不确定我们应该如何处理。如果错误在主干中，我们可以从主干创建一个修补程序分支，修复错误并 merge 到主干中。然后，创建一个 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。):

Answer 1

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

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