git flow 如何处理旧版本的修补程序或旧版本的点版本答案

【问题标题】：How does git flow handle hotfix to older release or point release of older releasegit flow 如何处理旧版本的修补程序或旧版本的点版本
【发布时间】：2016-08-28 21:02:16
【问题描述】：

在 master 远远超出该版本后，git flow 如何处理修补程序？

场景

针对 1.0 的工作在开发中执行，在发布/v1.0 发布分支上稳定并在快进合并中推送到主控，其中标签 v1.0 指向主控尖端和稳定分支的尖端
1.1 - 3.2 版的发布方式大致相同。
我们需要修复 1.0 中的一个错误
- v1.0 标记的分支
- 执行修复
- 合并到哪里？

Master 在遥远的未来，任何合并都不会是快进，为了好玩，假设会发生冲突。

我会合并以发布稳定分支并制作新标签吗？后续的修补程序会以此为出发点吗？

【问题讨论】：

它没有，git glow 假设你只有一个“实时”版本。
也就是说，您始终可以签出标记的版本，在那里创建一个新的修补程序分支，然后照常进行。
其实我认为 GitFlow 尤其适合在野外处理多个版本。我只使用它并精确地推荐它用于“打包”软件（用户下载/安装的地方）。如果是网络版（1 个单一实时版本），我会使用更简单的流程，例如 GitHub Flow。

标签： git git-flow

【解决方案1】：

nvie 在hotfix branches 上的部分解释了这些是……

... 非常类似于发布分支，因为它们也旨在为新的生产版本做准备，尽管是计划外的。

因此，当develop 中的当前内容还没有为正常的release 循环做好准备时，它们应该在最新的master 版本之上完成。

你想要在这里修补旧版本的是support 分支的概念，在最初的 git 流程发布后很久很久以前就讨论过这个概念，但是，afaik，从来没有完整的文档记录。

gitflow-avh 工具似乎确实很好地支持它们，因此您可能想在测试存储库中探索它：

Reference: git flow support · petervanderdoes/gitflow-avh Wiki

我确实在support 分支上找到了一些带有“信息”的帖子，但对他们的解释不太满意……鉴于缺乏关于它们的信息，我还是会链接它们：

【讨论】：

我同意支持分支上的文档不存在，甚至一般的文档可能需要更好的编写。使用 git-flow AVH，您可以从支持分支创建热修复，完成后它将合并回支持分支。当您还想使用相同的修补程序更新其他版本时，就会出现问题。这必须通过修补或采摘樱桃来完成。对于任何想要参与此讨论的人，请参阅 github 上的问题。 github.com/petervanderdoes/gitflow-avh/issues/161
你能给出一个git命令列表来回答这个问题吗？我的意思是回答“合并到哪里？”在问题中。 @PeterKahn 有一个具体的问题，能否给出相应的解决方案？
@FreeLightman 合并到无处！ :) “修补程序分支”不是这里的答案，“支持分支”是从标签派生的，并保持长期运行的分支，直到旧版本被弃用。
所以按照您的建议，发布（处于最新状态）都是主分支和修补程序分支上的标签？试着跟上它。我宁愿保持一致性：每个版本都有分支，而不仅仅是标记它。然后在一个非常旧的版本上进行热修复是很烦人的，但至少很容易跟踪每个版本的 HEAD。
@klaar 在 gitflow 中，hotfix 分支是短暂的，所以发布的 only 定义是 master 上的标签。仅当您需要更新/维护/修补旧版本时才使用支持分支分支主标记，您希望将其保持在最低限度 not 必须跟上支持分歧代码库。