在git-flow之后，您应该如何处理早期版本的修补程序？

如果您尝试遵循此处介绍的git-flow分支模型以及此处介绍的工具，则应如何处理这种情况：

您已经制作了1.0版和2.0版。然后，您需要对1.0进行修复。您从1.0标记创建了一个修补程序分支，并在那里实现了修补程序。但是那又怎样呢？

通常，您将合并到master并在其中放置1.1 release标签。但是您不能将1.1合并到master上的2.0之后的某个点。

我猜您可以将release标签放在hotfix分支上，但是那样会在包含发布标签的master旁边创建一个永久分支。那是正确的方法吗？

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

该线程包含更多信息，包括以下示例：

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来跟踪生产。相反，用树枝一样release1，release2等等。

用这种方法，您甚至可能不需要修补程序分支。您可以在release1分支上解决该问题。修复足够好后，release1.1在release1分支上创建一个标签。

git-flow假设您一次只支持一个发布行，而master可以方便地跟踪它。如果维护的数量超过1，则需要修改git-flow流程，以使您支持的单独发行版具有多个跟踪器（master-1，master-2）。除了或代替最新发布线的特定跟踪器（使用master代替master-2），您可以继续使用master跟踪最新发布线。

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

git config --add gitflow.multi-hotfix true此命令似乎对我有用！