Git 基于主干的开发版本&；修补程序问题

我很难理解如何处理以下情况：

功能A被提交到

master

作为commit

A

我们已经准备好发布

v1.0.0

，因此我们将提交

A

标记为

v1.0.0

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

rel-1.0.x

，用于QA

功能B被提交到

master

作为提交

B

QA批准

v1.0.0

，我们部署并删除

rel-1.0.x

分支

我们已经准备好发布

v2.0.0

，因此我们将commit

B

标记为

v2.0.0

，并从中创建一个

rel-2.0.x

分支用于QA

在生产中发现一个bug（

v1.0.0

），必须立即修复和部署

在这一点上，我不确定我们应该如何处理。如果bug在主干中，我们可以从主干中创建一个热修复分支，修复bug并合并到主干中。然后，从

v1.0.0

创建

rel-1.0.1

分支，从主干中选择修复程序，将其标记为

v1.0.1

并部署

现在我发现奇怪的是，

v1.0.1

提交与

master

不同，因为它是从

master

中挑选出来的，并在

rel-1.0.1

分支中标记的。此外，如果在

rel-2.0.x

中也需要修复，那么我们应该如何处理？我们是否应该再次从主干中挑选bug修复程序，并将其标记为不同的版本，例如

v2.0.1

这是我在做上述工作时得到的图形类型（请注意，v1.1代表上述文本的2.0版，这是在准备

v1.1

发行版时出现的

第二个修复功能）：

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

不过，我面临的一个挑战是，当master逐渐偏离生产中的内容时。发生这种情况的原因有很多，比如在master中有提交，这些提交在理论上已经准备好发布，但不知何故没有投入生产。我处理这个问题的方法是在生产环境中不断地重新处理提交树，使分歧保持在顶部。
我不明白您所描述的方法有什么困扰您的地方。看起来不错me@Francesco我觉得有点奇怪，所有版本化的提交都没有在
master
中结束（例如v1.0.2和v1.1.1）？通常是这样吗？我也经常读到，切利选择是要避免的，但在这里，我几乎总是切利选择错误修复。这也让我恼火的是，引入相同的补丁会产生两个新的热补丁版本号。一个用于当前发布的版本，一个用于准备发布的版本。我不反对cherry picks。我没有发现主控中没有发布标签有任何问题。我的建议是做对你有用的事。基于主干的很好，但可以进行调整。如果热修复程序分支也需要应用于当前版本分支
rel-2.0
，则可以合并或挑选从
hotfix
到
rel-2.0
的更改，然后标记新版本。