Git Branching/Merging 策略：release + hotfix 分支，master 的意义何在答案

【问题标题】：Git Braching/Merging strategy: release + hotfix branches, what's the point of masterGit Branching/Merging 策略：release + hotfix 分支，master 的意义何在
【发布时间】：2018-07-12 00:28:24
【问题描述】：

我正在研究一种基于 git 的分支/合并策略，以满足我组织的需求：我提到了GitFlow（链接：https://datasift.github.io/gitflow/IntroducingGitFlow.html）

并开始适应各种场景。这对于使用特性分支的正常开发和使用发布分支的发布都是有好处的。但是，当涉及到修补程序时，它会变得复杂。我们产品的几个不同版本部署到不同的客户端，我们需要能够为所有客户端部署修补程序。我相信 GitFlow 假设只有最新版本的产品部署在生产中，并且该策略通过在每个版本的主分支上创建标签来满足这一场景。如果需要修补程序，可以从 master 的最后一个标签创建一个新的修补程序分支，并将更改合并回 master 和 development 并从那里继续。但是，在我的情况下，我可能需要将修补程序部署到一个版本，该版本落后于 master 几个版本，我不能简单地将其合并回 master。我必须将它合并回原始发布分支和开发分支。我必须跟踪所有发布分支并对其进行适当的版本化。

我想知道这种情况是否有一个优雅的解决方案。此外，因为我不再从 master 上的标签中获取 hotfix 分支并合并回 master，所以同时拥有开发和 master 分支有什么意义呢？我不需要开发分支。功能分支可以直接合并到master，在发布时，我可以从master创建一个发布分支，一旦准备好，可以将它合并回master。有什么建议吗？

【问题讨论】：

标签： git merge branch

【解决方案1】：

作为mentioned here，Gitflow 非常适合具有预定发布周期的项目。

开发和掌握分支

此工作流使用两个分支来记录项目的历史，而不是单个主分支。 master 分支存储官方发布历史，develop 分支作为功能的集成分支。用版本号标记 master 分支中的所有提交也很方便。

所以：

我必须将它合并回原来的发布分支和开发分支。我必须跟踪所有发布分支并对其进行适当的版本化。

我想知道这种情况是否有一个优雅的解决方案

并非如此：需要在逐个版本的基础上评估向后移植修补程序（某些版本可能不需要修复）
但是你不需要将它合并到一个开发分支（除非修复仍然与下一个版本相关），只需要一个发布分支。

同时拥有一个开发分支和一个主分支有什么意义？我不需要开发分支

master 记录每个新版本（并且它的所有提交都代表一个新版本）。
从每个版本中，可以创建一个发布分支来托管任何演变（例如新的反向移植修复）

【讨论】：

需要将修补程序合并回开发，以便修补程序更改可以在即将发布的版本中使用。如果该错误已被另一个版本解决，则无需合并到开发中。
>>master 记录每个新版本（并且它的所有提交都代表一个新版本）。 --在这种情况下，发布由各个发布分支跟踪。我仍然可以保留主人，但它大多没用。
@DevOpsy 是的，master 只是一个账本 ro 记录官方新版本。而开发可以有许多中间提交。当然：您可以将两者混合使用。