以下git-flow应该如何处理早期版本的修补程序？

Question

如果您尝试按照混帐流分支模型，documented here与tools here，你应该如何处理这种情况：

你做出了一个1.0版本和2.0版本。然后你需要为1.0做一个修补程序。您可以从1.0标签创建一个修补程序分支并在那里实施修复。但是呢？

通常情况下，您将合并为主并在其中放置1.1版本标签。但是您无法将1.1合并到master上2.0之后的某个点上。

我想你可以把发布标签放在修补程序分支上，但是这会在主发行版旁边创建一个包含发布标签的永久分支。这是正确的方式吗？

Answer 1

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

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来跟踪生产。相反，请使用release1,release2等分支。

在此方法中，您甚至可能不需要修补程序分支。您可以修复release1分支上的问题。如果修复足够好，请在release1分支上创建一个release1.1标记。

Answer 3

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

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