当 master 领先几个版本时创建错误修复版本答案

【问题标题】：Create a bugfix release when master is several versions ahead当 master 领先几个版本时创建错误修复版本
【发布时间】：2016-04-08 15:24:43
【问题描述】：

我一直在考虑使用 git flow，但围绕修补程序的原始设计似乎存在漏洞。

假设您已经发布了多个版本 - 您的 master 有 0.1、0.2、0.3、1.0、1.1、2.0 等的标签。您在 0.2 中发现了一个错误，并希望在 0.2.1 版本中进行修复。发布标签在哪里？它不能进入master，因为那是2.0版。它只是在修补程序分支上吗？然后可以使用该分支以类似的方式创建 0.3.1 和 1.1.1 版本，使用 1.1.1 修补程序分支上的标记，并合并到待处理的版本分支中吗？

【问题讨论】：

Git-flow and master with multiple parallel release-branches的可能重复
在这里，我特意询问对旧版本的修复，该旧版本必须按顺序合并回新版本，直到达到 master
这个问题的答案也回答了你的问题，不是吗？
类似 - 您是否创建一个单独的修补程序并为您想要执行的每个支持版本从任何地方挑选更改？那些支持分支会永远存在吗？
我不知道，我不使用 git-flow，但据我所知，支持分支是测试版，并不是真正的生产就绪，所以它们的含义和处理可能会改变。

标签： git branch git-flow hotfix

【解决方案1】：

即使原始的 gitflow 从未“升级”过支持分支，您也会遇到另一个问题。原始的 git-flow 不允许您从支持分支创建修补程序开始。

首先，我假设您在 x.y.z 中使用 Semantic Versioning 2.0.0

如我所见，回答您的问题：您使用支持分支进行发布，现在的问题当然是您将保留和创建多少个支持分支。就个人而言，如果您支持旧版本，我会为 x.y 版本保留分支。

标签将继续在支持分支上。

如果需要在整个版本中一直实施修补程序，您可以通过两种方式来执行此操作：

按照您的建议挑选樱桃。
创建补丁并将补丁用于其他版本。

如果修补程序只是一个提交，我想你可以做一个 Cherry Pick，如果更多，我会使用 git format-patch 创建补丁并使用 git am 将它们添加到其他分支。

现在再次能够从您需要使用gitflow AVH Edition 的支持分支创建修补程序/错误修复/发布分支（免责声明：我开发了 gitflow AVH 版）

【讨论】：