GitFlow：release分支和master分支有什么区别？

Question

我刚刚看了一下这个 gitflow 速查表。我不理解release分支。

有人可以告诉我release和master分支之间的区别吗？

- Jordi

---

有没有关于将发布分支合并到主分支的时间推荐？我不确定在发布生产之前是否应该将发布分支合并到主分支，还是从发布分支中发布到生产，然后再合并到主分支。我的发布分支已经签署完毕。如果我将其合并到主分支并部署到生产环境，则不会测试该合并版本。理想情况下，由于我的主分支未被触及，因此从发布到主分支的任何合并都不应产生任何冲突或其他意外。但是，我不确定推荐什么。 - Anuj Khanna

@AnujKhanna 避免出现意外情况，这正是为什么推荐使用 git-flow 的原因。问题描述中附有一张备忘单，遵循它可以确保您的安全。此外，如果我有信心将发布分支合并到主分支，那么将其合并到生产环境中也应该是安全的。 - Jarmos

Answer 1

区别在于目标和过程。通常情况下，当你准备发布即将到来的版本时，会创建一个 release 分支。当所有应该发布的 feature 分支已经合并到 develop 分支中后，您就可以从 develop 分支中创建一个 release 分支，并仅提交 bug 修复或一些配置更改。换句话说，您尝试使其尽可能稳定。希望 release 分支足够稳定后，将其合并回 develop 和 master 分支中。master 分支的目的是始终拥有项目的最新稳定版本，可以部署到生产环境中。您永远不会直接提交到 master 分支，只能从 release 或 hotfix 分支中合并到 master 分支。还可以配置 CI/CD 工具以在 master 分支的任何更新上进行生产部署。

- Alexey Andrushkevich

Answer 2

一旦你希望在发布中有的所有功能都开发完毕，而不是将“develop”锁定到任何新提交，你就可以创建一个包含预期在下一个版本发布中的所有功能的“release branch”（而不是在主分支上），因为整个发布都应该经过测试并且可能会有一些漏洞修复...

• 在这个分支上，你只有错误修复、文档等，但没有新的功能
• 你的“develop”分支没有被锁定，所以下一个发布的新功能仍然可以提交/推送到“develop”并进行测试。
• “release branch”非常适合部署在staging/pre-prod环境上，并让QA测试您的发布。
• 一旦“release branch”稳定，您就可以将其合并到“master”并进入生产环境。如果“master”不稳定，您应该做热修复。

您可以查看以下链接了解更多解释：

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow http://nvie.com/posts/a-successful-git-branching-model/#feature-branches

- olibiaz

Answer 3

我认为你的问题源于常见的对GitFlow的误解。因此有必要对它进行澄清。

在GitFlow中，发布分支的生命周期很短暂。它们用于准备发布。发布分支的好处是让一个团队在另一个团队继续开发后续版本的功能时可以完善当前即将发布的版本。相比之下，主分支(master)则永久存在。

在GitFlow中，您不会从发布分支发布到生产环境。这不是发布分支的用途。这种误解可能来自于“发布分支”这个名称。主分支必须反映实际生产值得发布的版本。您将发布分支合并到主分支中，然后从主分支中发布（即创建构建）。GitFlow中面向生产环境的制品始终起源于主分支。您不能从任何其他分支中获得生产环境中的制品。本质上，每次合并到主分支都是GitFlow模型中的一个新的官方发布。

一旦发布结束（即将其合并到主分支中），发布分支就会消失，我认为从不久后被删除的分支发布到生产环境是灾难性的。

以上观点似乎对一些人来说是有争议的。但我认为这是经典的GitFlow思想，正如原始论文中所描述的。您会发现，有些人实际上从发布分支创建构建制品，然后将其放入生产环境中。当他们看到它起作用时，他们会回去合并到主分支中。（或者他们会忘记这一步）。我认为这不是GitFlow。

简而言之，这就是经典的GitFlow，您可以清楚地看到发布分支和主分支(master)之间的区别。

1. 在名为release/<something>的分支上准备发布。
2. 当准备好要发布时：将发布分支合并到master中。然后删除您的发布分支（它不再有用）。
3. 使用版本号对master进行标记，例如5.9.1。
4. 从master标记中创建可部署的工件。现在你拥有了一个版本（可能是用于生产环境的）。现在，在所有环境中测试这些工件：测试，暂存等。如果测试失败（尽管您在合并到master之前已经完成了测试），则您必须接受您现在拥有了一个放入废纸篓的版本5.9.1。接受它！您必须然后开始一个新的发布分支，例如release/5.9.2。
5. 最终，您可以将经过测试的工件放入生产环境中。如果出现问题（尽管经过了所有的测试），则再次必须创建一个新的版本。这意味着您要么重新开始一个新的发布分支，要么按照热修复工作流模型进行操作。

可以看出，在GitFlow中，一旦您合并到master，您可能已经完成了大量的测试，因此从master创建的版本在测试中失败的风险很小。

请注意，GitFlow当然不会阻止您从除master以外的所有其他分支创建工件，并将其用于任何环境（生产环境除外）的测试目的。

- peterh

Answer 4

在发布后，release 分支将被删除，但 master 将保持稳定。

- Li Jin