Following git-flow how should you handle a hotfix of an earlier release?

如果您尝试遵循 git-flow 分支模型 记录在案和 这里有工具，您应该如何处理这种情况:

您已经发布了一个1.0版本和一个2.0版本。然后你需要为1.0做一个修复程序。您可以在1.0标记之外创建一个修复分支，并在那里实现修复。然后呢？

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

我想您可以将发布标记放在修复程序分支上，但是这将在主服务器旁边创建一个永久性分支，其中将包含一个发布标记。这样对吗？

44762 次浏览
小开

有趣的问题！您链接的流程假定 master 可以跟踪生产。这只有在生产版本严格增加的情况下才有效。对于一个只有一个生产版本的网站来说，这是典型的事实。

如果您必须维护多个生产版本，一个分支来跟踪生产是不够的。一种解决方案是不使用 master 来跟踪生产。相反，使用像 release1、 release2这样的分支。

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

小开

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

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

小开
最佳答案

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

这个帖子有更多的信息 ，例如:

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
小开

Git config ——添加 gitflow. multi-hotfix true 这个命令似乎对我有用！


提交答案