遵循 git-flow 你应该如何处理早期版本的修补程序？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/16386323/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Following git-flow how should you handle a hotfix of an earlier release?
提问by Klas Mellbourn
If you try to follow the git-flow branching model, documented hereand with tools here, how should you handle this situation:
如果您尝试遵循此处记录的 git-flow 分支模型并使用此处的工具，您应该如何处理这种情况：
You have made a 1.0 release and a 2.0 release. Then you need to make a hotfix for 1.0. You create a hotfix branch off the 1.0 tag and implement the fix there. But what then?
您已经发布了 1.0 版和 2.0 版。然后你需要为 1.0 做一个修补程序。您从 1.0 标记创建一个修补程序分支并在那里实施修补程序。但是呢？
Normally you would merge to master and put a 1.1 release tag there. But you can't merge 1.1 to a point after 2.0 on master.
通常你会合并到 master 并在那里放一个 1.1 发布标签。但是您不能在 master 上将 1.1 合并到 2.0 之后的某个点。
I guess you could put the release tag on the hotfix branch, but that would create a permanent branch beside the master that would contain a release tag. Is that the right way?
我猜您可以将发布标签放在修补程序分支上，但这会在主分支旁边创建一个包含发布标签的永久分支。这是正确的方法吗？
采纳答案by Klas Mellbourn
It seems that there is a concept of a "support" branch in git flow. This is used to add a hotfix to an earlier release.
似乎在 git flow 中有一个“支持”分支的概念。这用于向早期版本添加修补程序。
This thread has more information, with these examples:
这个线程有更多信息，有这些例子：
git checkout 6.0
git checkout -b support/6.x
git checkout -b hotfix/6.0.1
... make your fix, then:
...进行修复，然后：
git checkout support/6.x
git merge hotfix/6.0.1
git branch -d hotfix/6.0.1
git tag 6.0.1
or using git flowcommands
或使用git flow命令
git flow support start 6.x 6.0
git flow hotfix start 6.0.1 support/6.x
... make changes then:
...然后进行更改：
git flow hotfix finish 6.0.1
回答by Andomar
Interesting question! The flow you linked assumes master can track production. That only works if production versions are strictly increasing. That's typically true for a website which has only one production version.
有趣的问题！您链接的流程假定 master 可以跟踪生产。这仅在生产版本严格增加时才有效。对于只有一个生产版本的网站来说，这通常是正确的。
If you have to maintain multiple production versions, one branch to track production is not enough. A solution is not to use master to track production. Instead, use branches like release1, release2, etc.
如果您必须维护多个生产版本，一个分支来跟踪生产是不够的。一个解决方案是不使用 master 来跟踪生产。相反，用树枝一样release1，release2等等。
In this approach, you may not even need a hotfix branch. You could fix the problem on the release1branch. When the fix is good enough, create a release1.1tag on the release1branch.
在这种方法中，您甚至可能不需要修补程序分支。你可以在release1分支上解决这个问题。当修复足够好时，release1.1在release1分支上创建一个标签。
回答by Bert F
git-flow assumes your are only supporting one release line at a time, conveniently tracked by master. If you are maintaining more than 1, then you will need to modify git-flow process to have multiple trackers of your separate releases you are supporting (master-1, master-2). You could continue to use master to track the most recent release line, in addition to or in lieu of a specific tracker for the most recent release line (master in lieu of master-2).
git-flow 假设你一次只支持一个发布行，方便 master 跟踪。如果您维护 1 个以上，那么您将需要修改 git-flow 流程以拥有您支持的单独版本的多个跟踪器（master-1、master-2）。您可以继续使用 master 来跟踪最新的发布行，除了或代替最近发布行的特定跟踪器（master 代替 master-2）。
Unfortunately, any git-flow tooling you may be using will probably need to be modified, but hopefully you are familiar enough with git-flow process to handle this specific case directly with git commands.
不幸的是，您可能使用的任何 git-flow 工具都可能需要修改，但希望您对 git-flow 过程足够熟悉，可以直接使用 git 命令处理这种特定情况。
回答by Laila
git config --add gitflow.multi-hotfix true This command seems to work for me!
git config --add gitflow.multi-hotfix true 这个命令似乎对我有用！
