如果你尝试遵循 git-flow 分支模型，documented here 和 tools here，你应该如何处理这种情况：
您已经发布了 1.0 版本和 2.0 版本。然后你需要为 1.0 做一个修补程序。您从 1.0 标记创建一个修复程序分支并在那里实施修复程序。但是然后呢？
通常你会合并到 master 并在那里放置一个 1.1 版本标签。但是你不能将 1.1 合并到 master 上 2.0 之后的某个点。
我想你可以将发布标签放在修补程序分支上，但这会在包含发布标签的 master 旁边创建一个永久分支。这样做对吗？
【问题讨论】：
标签： git branch git-flow hotfix
似乎在git flow中有一个“支持”分支的概念。这用于向早期版本添加修补程序。
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
【讨论】：
有趣的问题！您链接的流程假设 master 可以跟踪生产。这仅在生产版本严格增加时才有效。对于只有一个生产版本的网站来说，这通常是正确的。
如果你必须维护多个生产版本，一个分支来跟踪生产是不够的。一个解决方案是不使用 master 来跟踪生产。相反，请使用 release1、release2 等分支。
在这种方法中，您甚至可能不需要修补程序分支。您可以在 release1 分支上解决问题。当修复足够好时，在release1 分支上创建一个release1.1 标记。
【讨论】：
git-flow 工具不适合如果您必须支持多个生产版本。在此答案中提出的工作流程中，根本没有使用 master 。你可以命名开发分支master，毕竟它只是一个名字。
git-flow 假设您一次只支持一个发布行，由 master 方便地跟踪。如果您维护超过 1 个，那么您将需要修改 git-flow 流程以拥有您支持的单独版本的多个跟踪器（master-1，master-2）。您可以继续使用 master 来跟踪最近的发布行，除了或代替最近发布行的特定跟踪器（master 代替 master-2）。
不幸的是，您可能使用的任何 git-flow 工具都可能需要修改，但希望您对 git-flow 流程足够熟悉，可以直接使用 git 命令处理这种特定情况。
【讨论】：
git flow 进程，那么它会有所不同。如果某个模型应该被修复（而不仅仅是扩展），那么它就像作者所说的那样成功。请查看我对我们正在讨论的主题的回答。
git config --add gitflow.multi-hotfix true 这个命令似乎对我有用！
【讨论】：