Gitflow为什么需要主分支(master)?

Question

在GitFlow中，所有的发布分支最终都会：

1. 合并到主分支
2. 合并到开发分支
3. 给主分支打上标签
4. 删除发布分支

但是为什么我们不直接：

1. 给发布分支打上标签
2. 合并到开发分支
3. 删除发布分支

如果遇到热修复，我们可以：

1. 从最新的标签分支创建一个分支
2. 进行热修复
3. 给该热修复分支打上标签
4. 合并到开发分支
5. 删除热修复分支

- Mahmoud Adel Farid

Answer 1

您几乎在描述一个发布流程分支模型：

• 开发人员与公共主干分支合并（称为develop或master）
• 当您准备发布时，从主干分支分支（称为release/r-1.2等）
• 当您发现新版本存在问题时，创建热修复分支（hotfix/fix-something）
• 像普通开发一样将您的热修复合并到主干线上
• 将热修复合并/挑选到您的发布分支中
• 发布分支表示生产环境，当它部署到该环境时

没有最终合并到生产分支 - 没有必要，因为发布分支是相同的。

一旦旧的发布分支被下一个分支取代，如果不再需要进行审核，则可以删除它。

VSTS团队对此有很好的文档： https://learn.microsoft.com/en-gb/azure/devops/devops-at-microsoft/release-flow

- James

---

链接现在已经失效了，但是这里有另一个链接：http://releaseflow.org/ - Nikolaj Š.

Answer 2

让我试着在这里表达我的理解，

Git分支命名约定 master, develop & release 已经被明确定义并采用以与普遍同步。这并不意味着你必须遵循，你可以定义自己的方式并推送给你的客户和用户，许多组织遵循通用命名约定以避免不必要的混淆。

在Mercurial中，许多人遵循分支命名 default 而不是 master。

一行定义：

master  : Ready Product (Public Available)

develop : Requirements/bugs/Improvements Implementation In Progress (Not recommended to use)

release : Preparing to `Ready Product` (Private or internal)

tag master : Stable Product with defined features.

你可以参考这个 这个 这个 获取更多信息

- ntshetty

---

我认为使用“master”表示当前开发的惯例并不少见，而且随着像Github和Atlassian这样的主要提供商的支持而不断增加。 - max630

但是为什么你需要“master: Ready Product”分支呢？ 任何标签都应该是“Ready Product”，可以分支。 - Mahmoud Adel Farid

@MahmoudAdelFarid，假设您需要实现100个功能并使用敏捷方法进行工作。决定分为5个里程碑交付。这意味着每个里程碑应该实现20个功能。在这种情况下，“develop”分支将通过5次合并到“master”（每个里程碑一次）。最好为每个里程碑设置一个“tag”以便跟踪。 - ntshetty

Answer 3

关于为什么在Gitflow中需要 master 分支（develop 分支无法替代）的主要原因：

• master 分支上的所有版本都应该足够稳定，因为它用于产品环境。
• 而对于 develop 分支，所有开发人员都可以直接推送他们的工作，即使没有经过验证。这意味着，develop 分支可能是“脏”的，这将导致生产/实际环境崩溃。

- Marina Liu

---

如果你在develop分支上使用一个标签来表示部署到生产环境中的版本，你可以从该标签上创建分支，进行热修复、部署，并将更改合并回develop分支。 - luizfzs