使用 git-flow 的多个开发分支
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/8579056/
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
Multiple development branches with git-flow
提问by LiKao
I am currently looking a lot into git-flow, and trying to figure out, how to use it for the projects I am involved on.
我目前正在研究 git-flow，并试图弄清楚如何将它用于我参与的项目。
I have looked at the various git-flow tutorials and I am fairly familiar with git. Hence I do not need any tips on git alone, but directly on the workflow with git-flow.
我看过各种 git-flow 教程，我对 git 相当熟悉。因此，我不需要单独使用 git 的任何提示，而是直接使用 git-flow 的工作流程。
Here is the situation:
这是情况：
When I relase a version (let's call it 1.0), this get's branched of develop, which is fine. Let's say now I start working on 2.0, adding new features. And of course I want to merge them back onto develop, once I am done. Now hotfixing on 1.0 is fine, so let's also say I produce several versions 1.0.1, 1.0.2 etc. All these will also update the develop branch, which is also nice. So far now hassle, I can develop features for 2.0 and hotfixes for 1.0.x independtly.
当我发布一个版本（我们称之为 1.0）时，这个 get 是 develop 的分支，这很好。假设现在我开始研究 2.0，添加新功能。当然，一旦我完成，我想将它们合并回开发。现在在 1.0 上进行热修复很好，所以假设我生产了几个版本 1.0.1、1.0.2 等。所有这些也会更新开发分支，这也很好。到目前为止很麻烦，我可以独立开发 2.0 的功能和 1.0.x 的修补程序。
However let's say someone requests a new feature for a 1.1 release. Now I have a problem. If I create a feature branch, this will be based upon the develop branch, which might already contain 2.0 stuff, which I might not want in this 1.1 release.
但是，假设有人请求 1.1 版本的新功能。现在我有一个问题。如果我创建一个功能分支，这将基于开发分支，它可能已经包含 2.0 的东西，我可能不想要在这个 1.1 版本中。
Is there a simple way, to handle these 2.0 and 1.1 changes independtly?
有没有一种简单的方法来独立处理这些 2.0 和 1.1 的变化？
There are several possibilities I see already:
我已经看到了几种可能性：
create a new branch at the last release position on develop. Rebase the develop onto this position and rename the other develop branch. However then this branch would not contain any hotfixes from 1.0.1 etc.
Do not merge back features for 2.0 before 2.0 is done. However then I would have to leave a lot of unmerged changes open until the last moment. Also this does not help, if 2.0 get's released and afterwards changes to 1.0.x are requested.
在开发的最后一个发布位置创建一个新分支。将开发重新定位到此位置并重命名另一个开发分支。但是，此分支将不包含来自 1.0.1 等的任何修补程序。
在 2.0 完成之前不要合并回 2.0 的功能。但是，我将不得不将许多未合并的更改保留到最后一刻。这也无济于事，如果 2.0 get 已发布，然后请求更改为 1.0.x。
Is this possible at all with git flow? I.e. basing releases upon an earlier release once the work for a newer release has been started or even finished?
使用 git flow 可以实现吗？即，一旦新版本的工作已经开始甚至完成，就基于较早的版本发布？
采纳答案by meagar
Is this possible at all with git flow?
使用 git flow 可以实现吗？
Anything is possible using git-flow as a series of best-practices rather than a hard rule. Just open your feature branches from your 1.0release branch instead of from your developbranch.
使用 git-flow 作为一系列最佳实践而不是硬性规则，一切皆有可能。只需从您的1.0发布分支而不是从您的develop分支打开您的功能分支。
回答by Adam Dymitruk
More on "git-flow improved":
更多关于“git-flow改进”：
https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
The key is to start features from the point of last release. Whether you have 1 or more supported versions that are published should not be an issue.
关键是从上次发布的点开始功能。您是否有 1 个或多个已发布的受支持版本应该不是问题。
UPDATE:
更新：
I have it rewritten - in blog form:
我已经重写了 - 以博客形式：
回答by Aaron Lozier
I realize this is an old question, but I just found a fairly simple way of handling it on my end.
我意识到这是一个老问题，但我刚刚找到了一种相当简单的方法来处理它。
On my development server I basically have two working copies, one for v1.0 and another for v2.0.
在我的开发服务器上，我基本上有两个工作副本，一个用于 v1.0，另一个用于 v2.0。
I then create a separate "develop" branch for v2.0, and when I run "git flow init" on the 2.0 environment, I use this as my "next release" branch.
然后我为 v2.0 创建一个单独的“develop”分支，当我在 2.0 环境中运行“git flow init”时，我将它用作我的“下一个版本”分支。
I am sure you could do the same for the master branch, but for my purposes this was sufficient.
我相信你可以对 master 分支做同样的事情，但对我来说这已经足够了。
回答by Anton
I believe if you want to support two versions of app at the same time it will be better to create two different repositories for that.
我相信如果您想同时支持两个版本的应用程序，最好为此创建两个不同的存储库。
