git - 遵循 git-flow 你应该如何处理早期版本的修补程序？

Question

如果您尝试遵循此处记录的 git-flow 分支模型并使用此处的工具，您应该如何处理这种情况：

您已经发布了 1.0 版本和 2.0 版本。然后你需要为 1.0 做一个修补程序。您从 1.0 标记创建一个修复程序分支并在那里实施修复程序。但那又如何呢？

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

我想您可以将发布标签放在修补程序分支上，但这会在包含发布标签的主服务器旁边创建一个永久分支。那是正确的方法吗？

Answer 1

似乎在 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

Answer 2

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

如果你必须维护多个生产版本，一个分支来跟踪生产是不够的。一个解决方案是不使用 master 来跟踪生产。相反，请使用release1,release2等分支。

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

Answer 3

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

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

Answer 4

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