主分支和发布分支有什么作用？

Question

"主分支" 是一个已经准备好可以被最终用户下载的产品。

但是还有 "发布分支" - 我不知道这些分支是为谁准备的。是为客户发布的吗？还是为了QA（质量保证）？

显示分支的图像

- newBike

---

哪个答案是正确的？ - Subrato Pattanaik

Answer 1

一旦develop分支已经具备发布所需的足够功能，或者预定的发布日期即将到来，您就要从develop分支中派生出一个发行分支。创建此分支开始下一个发布周期，因此在此点之后不能添加新功能。只有修复错误、文档生成和其他发布相关任务应该放在这个分支中（包括测试）。一旦准备好发布，发行版将合并到主分支并附带版本号标记。此外，它应该被合并回develop分支，可能因为发布启动以来它已经有所进展。

使用专用分支来准备版本发布可以让一个团队在另一个团队继续开发下一个版本的功能时对当前版本进行完善。它还创建了定义良好的开发阶段（例如，“本周我们正在为4.0版本做准备”，并且实际上可以在存储库的结构中看到它）。

更多关于分支的信息请查看此处

- minas

---

你用什么工具创建了这个图表？ - Daniel Harms

如果有人打算发起一个合并请求来合并到你的主分支，该怎么办？ - rtribaldos

推荐从哪个分支（主分支或发布分支）准备发布的部署包？ - Pylyp Lebediev

@RicardoTribaldos 如果是这样的话，您可以不允许合并。此外，在GitHub、GitLab或任何其他服务中，您可以配置合并规则和人们可以合并的分支。还有代码审查。 - Christian Blanco

@PylypLebediev 正常情况下，我们应该从develop分支中获取最新的更新版本，然后创建release/分支，并将其合并到master和develop分支中。 - Christian Blanco

@DanielHarms 图片可以在这里找到。 - Christian Blanco

Answer 2

如原V.Driessen的帖子中所解释：

Master 是一个永久分支，始终反映出可供生产使用的状态。因此，它适用于用户可以在市场上下载的产品。

Release 是一个临时支持分支，用于支持新产品发布的准备工作。这主要包括 bug 修复、文档等，正如 minas 所指出的那样。

- user2867331

Answer 3

在您提供的图表中，是的，“master”用于发布给用户的“成品”。（不过，并非每个人都使用“master”这种方式。）

在图表中，每次团队准备发布新的“成品”版本时，他们会创建一个新的“发布”分支。在准备发布期间，他们不会向“发布”分支添加任何新功能--添加新功能可能会导致新的错误，而且他们正在尽力使“发布”版本尽可能稳定，以便公开发布。他们会添加提交到“发布”分支以修复最终测试中发现的任何问题，优化粗糙的地方等。因此，创建“发布”分支标志着“特性冻结”点--他们决定只有他们已经开发的功能将进入下一个公共发布版本。

一旦他们准备好公开发布产品的新版本，他们将“发布”分支合并到“master”中，并在用于构建公开可下载产品的提交上打标签。（如果他们发布1.0版，他们可能会标记提交为“1.0”，依此类推。）

与此同时，他们在开发新功能时，会创建新的“特性”分支（从“develop”分支分离出来）并提交它们。当一个新功能工作正常时，他们会将其分支合并回“develop”。 “develop”始终在不断前进。

- Alex D

---

谢谢您详细的回答，请进一步澄清这个步骤：“他们将“发布”分支合并到主分支并标记用于构建可公开下载产品的提交。” 这个版本（从主分支构建）是否需要由QA重新测试（最终测试）？因为在合并、环境配置等方面可能会出现意外情况。 - Phong Nguyen

@ThinkTwiceCodeOnce 这取决于您工作流程的细节。如果您仅允许主分支通过合并发布分支向前推进，那么master上永远不应该有一个提交不在最新的发布分支上。或者，您可以直接向master添加提交，但在这样做时，请确保它们始终被挑选到下一个发布分支上。将提交添加到master而不将其添加到下一个发布分支是没有意义的。 - Alex D