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

【问题标题】：In which branch should a beta release be tagged?应该在哪个分支中标记 beta 版本？
【发布时间】：2017-01-12 16:12:14
【问题描述】：

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

我们有一个发布分支来准备版本x.0.0，但在发布x.0.0 之前，我们想发布一个测试版（x.0.0-beta）。在这种情况下，发布分支应该合并到master，然后在master 上标记x.0.0-beta，还是应该在发布分支上标记x.0.0？

其他问题：发布候选版 (x.0.0-rc1) 的过程是否与测试版相同？

【问题讨论】：

【解决方案1】：

我建议您将 x.0.0-beta 标记放在发布分支上，一旦您准备好在某个地方发布 beta 版本。您实际上可能想走得更远，标记为x.0.0-beta0001，以便您可以根据需要拥有多个测试版。

一旦您靠近发布，您也可以根据需要使用x.0.0-rc1 标记发布分支。

然后，一旦将 release 分支合并到 master 并最终重新合并到 develop 分支，您将使用最终版本号标记 master 分支。

这种方法取自 GitVersion 实用程序中 git-flow 的实现，记录在这里：

【讨论】：

【解决方案2】：

据我了解，所有版本都应合并到主分支并标记在主分支上。因为所有的 Release 分支都应该遵循这个流程。语义版本控制应防止人们更新到已发布的 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 分支，以及尚未合并到 master 分支的提交？
我暗示要合并到master，让我明确添加答案。
Master 在大多数情况下被认为是一个稳定的分支。合并测试版和预发布版会使其成为一个不稳定的分支。
@ikke：这似乎是这个问题的根源。在我的建议中，我们将稳定定义为经过测试并且最多包含运行时错误的代码。与 develop 分支相反，其中新功能可能无法按预期工作，或者可能无法与另一个新功能一起使用。就像我在答案中所说的那样，语义版本控制将使这个系统保持在一起。 NPM、Bower、Composer 不会破坏您的系统，具体取决于使用此流程。