应该在哪个分支中标记beta版本？

Question

在哪个分支中应该根据git-flow标记beta版本？

我们有一个发布分支准备版本x.0.0,但在发布之前x.0.0我们想发布一个beta(x.0.0-beta).master在这种情况下是否应合并发布分支,然后进行标记x.0.0-beta,master或者是否应在发布分支上标记此beta版本x.0.0？

附加问题:候选发布版(x.0.0-rc1)的程序与beta相同吗？

Answer 1

我建议您将x.0.0-beta标签放在发布分支上,一旦您准备好在某个地方发布测试版.实际上,您可能希望进一步使用标记,x.0.0-beta0001以便根据需要可以拥有多个测试版.

一旦接近发布版,您也可以x.0.0-rc1根据需要标记发布分支.

然后,一旦您将发布分支合并到master中,并最终返回到develop,您将使用最终版本号标记master分支.

这种方法取自GitVersion实用程序中git-flow的实现,该实用程序在此处记录:

Answer 2

根据我的理解，所有版本都应该合并到主分支并在主分支上标记。因为所有发布分支都应遵循此流程。语义版本控制应该防止人们更新到已发布的 alpha/beta/RC 版本。

这可以让你的流程干净、直接。IE 没有分支开放以供日后清理。在提高版本号并测试代码后，您总是以相同的方式完成发布分支。

选修的

您可以在真正发布后删除特定版本的所有初步标签。这又是为了保持你的流程干净。因为人们可能不会检查完整稳定版本的“不稳定”版本。

1.2.0-alpha
1.1.0
1.1.0-rc2
1.1.0-rc1
1.0.0
1.0.0-beta1
1.0.0-alpha1

会成为

1.2.0-alpha
1.1.0
1.0.0

我暗示合并到master，让我明确地添加答案。 (3认同)
@ikke：这似乎是这个问题的根源。在我的建议中，我们将稳定定义为已经过测试并且最多包含运行时错误的代码。与“开发”分支相反，在“开发”分支中，新功能可能无法按预期工作，或者可能无法与另一个新功能一起工作。就像我在答案中所说的那样，语义版本控制将使这个系统保持在一起。NPM、Bower、Composer 不会因为使用此流程而破坏您的系统。 (2认同)