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

Question

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

1. 功能 A 致力于

   master

   作为提交

   A

   。
2. 我们已准备好发布

   v1.0.0

   ，因此我们将提交

   A

   标记为

   v1.0.0

   ，并从中创建一个发布分支

   rel-1.0.x

   以进行质量检查。
3. 功能 B 致力于

   master

   作为提交

   B

   。
4. QA 批准

   v1.0.0

   ，我们部署并删除

   rel-1.0.x

   分支。
5. 我们已准备好发布

   v2.0.0

   ，因此我们将提交

   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 中的提交理论上已经准备好发布，但不知何故没有投入生产。我处理这个问题的方法是在生产中不断重新工作提交树，以便分歧保持在顶部。

Answer 2

始终将您的提交拉到 master，然后挑选发布分支。所有提交都将在 master 中