为什么我们需要师父

Question

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

1. 合并为主人
2. 合并发展
3. 标签母版
4. 删除发布分支

但我们为什么不

1. 标记发布分支
2. 合并发展
3. 删除发布分支

万一有热修复，我们可以

1. 最新标签的分支
2. 做修补程序
3. 标记那个热修复分支
4. 合并发展
5. 删除修补程序分支

Answer 1

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

• 开发人员与公共主线分支合并(称为开发或主分支)
• 当您准备从主线中释放分支时(称为ready /R-1.2等等)
• 当您发现新版本的问题时，创建一个修复分支( hotfix /fix-什么的)
• 将您的修补程序像普通dev一样合并到您的主线中。
• 合并/樱桃将修补程序选择到发布分支中
• 发布分支表示将其部署到该环境中的产品。

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

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

VSTS团队很好地记录了这一点：https://learn.microsoft.com/en-gb/azure/devops/devops-at-microsoft/release-flow。

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.

您可以参考这 这 这获得更多信息。

Answer 3

主要原因是在gitflow中需要master分支(不能替换develop分支)：

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