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

Question

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

1. 功能A被提交master为commit A。
2. 我们准备好发布了，v1.0.0因此我们将commit标记A为，v1.0.0然后rel-1.0.x从中创建一个发布分支以进行质量检查。
3. 功能B被提交master为commit B。
4. 质量检查批准v1.0.0，我们部署并删除rel-1.0.x分支。
5. 我们已经准备好发布，v2.0.0因此我们将commit标记B为，v2.0.0并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发行版时发生的）。

Answer 1

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

不过，我面临的一个挑战是，master 与生产环境的差异越来越大。发生这种情况的原因有很多，例如 master 中的提交理论上已经准备好发布，但不知何故没有投入生产。我处理这个问题的方法是在生产中不断重新工作提交树，以便分歧的部分保留在顶部。