gitflow 为什么我们需要master答案

【问题标题】：gitflow why do we need mastergitflow 为什么我们需要master
【发布时间】：2018-05-09 23:46:58
【问题描述】：

在 gitflow 中，所有的发布分支最终都是

合并为主
合并发展
标签主
删除发布分支

但是我们为什么不直接

标记发布分支
合并发展
删除发布分支

如果有修补程序，我们可以

最新标签的分支
做修补程序
标记那个热修复分支
合并发展
删除修补程序分支

【问题讨论】：

标签： git git-flow

【解决方案1】：

您几乎是在描述发布流分支模型：

开发人员合并到一个公共主线分支（称为开发或主分支）
当您准备好从主线发布分支时（称为 release/r-1.2 等）
当您发现新版本存在问题时，请创建一个修补程序分支 (hotfix/fix-something)
像普通开发人员一样将修补程序合并到主线中
合并/樱桃选择修补程序到您的发布分支
发布分支在部署到该环境时代表生产

没有最终合并到生产分支 - 因为发布分支是一样的，所以不需要它。

一旦旧版本分支被下一个版本取代，如果不再需要用于审计目的，可以将其删除。

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

【讨论】：

链接已失效，但这里有另一个链接：releaseflow.org

【解决方案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.

您可以参考This This This了解更多信息

【讨论】：

我想说master 用于当前开发的约定并没有不那么受欢迎，并且在 github 和 atlassian 等主要供应商的支持下不断上升。
但是为什么你需要“master: Ready Product”分支任何标签都应该是可以分支的“Ready Product”
@MahmoudAdelFarid 假设您需要实现 100 个功能并以敏捷方式工作。决定交付 5 英里的石头。这意味着每个里程碑应该实现 20 个功能。在这种情况下。 develop 分支与 master 合并 5 次（在每个里程碑中一次）最好有 tag 来跟踪每个里程碑。

【解决方案3】：

在gitflow中master分支是必要的（develop分支不能被替换）的主要原因：

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

【讨论】：

但是如果你在开发分支上使用标签来指示部署到生产的版本，你可以从标签分支，做修补程序，部署，然后合并回开发。