如果您尝试遵循git-flow分支模型documented here和tools here，您应该如何处理这种情况：
您已发布1.0版本和2.0版本。然后你需要为1.0创建一个修补程序。您从1.0标记创建一个修补程序分支，并在那里实现修复。那么呢？
通常你会合并到master并在那里放一个1.1版本标签。但是你不能将1.1合并到2.0之后的一个点上。
我猜你可以把release标签放在hotfix分支上，但是这会在master上创建一个包含release标签的永久分支。这是正确的方法吗？
答案 0 :(得分：59)
似乎有一个＆＃34;支持＆＃34;的概念。 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
答案 1 :(得分：28)
有趣的问题！您链接的流程假定master可以跟踪生产。这仅适用于生产版本严格增加的情况。对于只有一个生产版本的网站来说，这通常是正确的。
如果您必须维护多个生产版本，那么一个跟踪生产的分支是不够的。解决方案不是使用master来跟踪生产。相反，请使用release1，release2等分支
在这种方法中，您甚至可能不需要修补程序分支。您可以在release1分支上修复问题。如果修复程序足够好，请在release1.1分支上创建release1标记。
答案 2 :(得分：6)
git-flow假设您一次只支持一个释放线，由主人方便地跟踪。如果您维护的数量超过1，那么您将需要修改git-flow进程以使您支持的单独版本的多个跟踪器（master-1，master-2）。您可以继续使用master来跟踪最新的版本行，除了或代替最新版本行的特定跟踪器（master代替master-2）。
不幸的是，您可能正在使用的任何git-flow工具都可能需要修改，但希望您对git-flow进程非常熟悉，可以直接使用git命令处理这个特定情况。
答案 3 :(得分：0)
git config --add gitflow.multi-hotfix是 该命令似乎对我有用！