遵循git-flow，您应该如何处理早期版本的热修复？

Question

如果你尝试遵循git-flow分支模型，documented here和tools here，你应该如何处理这种情况：

您已经发布了1.0版本和2.0版本。然后你需要为1.0做一个热修复。您可以在1.0标记上创建一个热修复分支，并在那里实现修复。但是，然后呢？

通常情况下，您会合并到master，并在那里放置1.1版本标签。但在master上，你不能将1.1合并到2.0之后的某个点。

我猜你可以把发布标签放在热修复分支上，但这会在主分支旁边创建一个永久的分支，它将包含一个发布标签。这条路对吗？

Answer 1

似乎在git flow中有一个"support“分支的概念。这用于将热修复程序添加到早期版本。

This thread has more information，具有以下示例：

git checkout 6.0
git checkout -b support/6.x
git checkout -b hotfix/6.0.1

..。完成你的修复，然后：

git checkout support/6.x
git merge hotfix/6.0.1
git branch -d hotfix/6.0.1
git tag 6.0.1

或使用git flow命令

git flow support start 6.x 6.0
git flow hotfix start 6.0.1 support/6.x

..。然后进行更改：

git flow hotfix finish 6.0.1

Answer 2

有趣的问题！您链接的流程假设master可以跟踪生产。这只有在生产版本严格增加的情况下才有效。对于一个只有一个生产版本的网站来说，这通常是正确的。

如果您必须维护多个生产版本，那么跟踪生产的一个分支是不够的。一种解决方案是不使用master来跟踪生产。取而代之的是，使用release1、release2等分支。

在这种方法中，您甚至可能不需要热修复分支。您可以在release1分支上修复该问题。当修复足够好时，在release1分支上创建一个release1.1标记。

Answer 3

git-flow假设你一次只支持一个版本行，由master方便地跟踪。如果您维护的版本多于1个，那么您将需要修改git-flow流程，以拥有多个您支持的单独版本的跟踪器(master-1，master-2)。您可以继续使用master来跟踪最新的发布行，作为最新发布行的特定跟踪器的补充或替代(master代替master-2)。

不幸的是，您可能正在使用的任何git-flow工具都可能需要修改，但希望您对git-flow过程足够熟悉，可以直接使用git命令处理这种特定情况。