基于主干的开发版本＆amp;修补程序问题

Question

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

1. 功能A承诺master作为提交A。
2. 我们已准备好发布v1.0.0，因此我们将提交A标记为v1.0.0，我们会为其创建一个发布分支rel-1.0.x以进行质量检查。
3. 功能B承诺master作为提交B。
4. 质量检查批准v1.0.0，我们部署并删除rel-1.0.x分支。
5. 我们已准备好发布v2.0.0，因此我们将提交B标记为v2.0.0，并为其创建rel-2.0.x分支以进行质量检查。
6. 在生产中发现了一个错误（v1.0.0），必须立即修复并部署。

此时我不确定我们应该如何应对。如果bug在trunk中，我们可以从trunk创建一个hotfix分支，修复bug并合并到trunk中。然后，从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提交，但由于某种原因并未投入生产。我解决该问题的方法是在生产中不断重做提交树，以使分歧处在首位。