使用 git-flow 的多个开发分支答案

【问题标题】：Multiple development branches with git-flow使用 git-flow 的多个开发分支
【发布时间】：2011-12-20 16:59:23
【问题描述】：

我目前正在研究 git-flow，并试图弄清楚如何将它用于我参与的项目。

我看过各种 git-flow 教程，我对 git 相当熟悉。因此，我不需要任何关于 git 的提示，而是直接使用 git-flow 的工作流程。

情况如下：

当我发布一个版本（我们称之为 1.0）时，这个 get 是 develop 的分支，这很好。假设现在我开始研究 2.0，添加新功能。当然，一旦完成，我想将它们合并回开发中。现在在 1.0 上修复就可以了，所以假设我生产了几个版本 1.0.1、1.0.2 等。所有这些也会更新开发分支，这也很好。到目前为止，现在很麻烦，我可以独立开发 2.0 的功能和 1.0.x 的修补程序。

但是，假设有人请求 1.1 版本的新功能。现在我有一个问题。如果我创建一个功能分支，这将基于开发分支，它可能已经包含 2.0 的东西，我可能不希望在这个 1.1 版本中。

有没有一种简单的方法来独立处理这些 2.0 和 1.1 的更改？

我已经看到了几种可能性：

在开发的最后一个发布位置创建一个新分支。将开发重新定位到此位置并重命名另一个开发分支。但是，此分支将不包含 1.0.1 等的任何修补程序。
在 2.0 完成之前，不要合并 2.0 的回退功能。但是，我将不得不保留许多未合并的更改，直到最后一刻。这也无济于事，如果 2.0 get 已发布，然后请求更改为 1.0.x。

git flow 有可能吗？ IE。一旦新版本的工作已经开始或什至完成，则基于早期版本发布？

【问题讨论】：

嗨，git-flow现在支持这个功能吗？
google“每个功能的分支”。 CI 人群对此表示强烈反对——特别是颠覆倡导者。如果使用正确的工具，我的文章就是一个论据。希望它可以帮助人们理解问题的症结——尤其是讨论的链接——不需要 google+ 帐户来阅读它。它被复制到我网站上的单独页面中。

标签： git version-control git-flow branching-strategy

【解决方案1】：

更多关于“git-flow 改进”：

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

关键是从上次发布的那一点开始功能。您是否有 1 个或多个已发布的受支持版本应该不是问题。

更新：

我已经重写了 - 以博客形式：

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

【讨论】：

如果不创建帐户并同意表单，我将无法访问 google plus。博客上有这个副本吗？
@drudru 您无需拥有帐户即可查看该链接。

【解决方案2】：

git flow 有可能吗？

使用 git-flow 作为一系列最佳实践而不是硬性规则，一切皆有可能。只需从 1.0 发布分支而不是 develop 分支打开功能分支。

【讨论】：

好吧，我的措辞不好。我不应该使用“可能”这个词，而应该使用“易于支持”之类的词。让我看看我是否正确理解了你的答案：如果我做一个git flow feature start 这个功能是当前位置的分支？ IE。如果我在master，它会从那里分支吗？因为我观看的教程给人的印象是无论当前签出什么，它都会从develop 分支出来。我想唯一的问题是让 master 保持正确的状态（例如，当 1.1 在 2.0 之后发布时）。
如果你这样做 git flow feature start 你已经迷路了，因为 git-flow 从根本上不支持你正在做的事情。你必须使用 git，而不是 git-flow 来实现你想要的。查看您的1.0 分支和git checkout -b feature/my-feature。您将拥有一个使用 1.0 作为起点的新分支。
好的，我明白了。我认为有一种方法可以直接在 git-flow 中处理这个问题。不知何故，我猜这是多个客户要求不同功能的共同功能，因此它可能以某种方式直接存在于 git-flow 中。看来这毕竟不是那么普遍。我想我必须更多地考虑如何使 git-flow 工作流适应我们的用例。
@meagar “首先是一系列最佳实践”我认为没有人会不同意，但这只是故事的一半。也是 (by definition)“提供高级存储库操作的 Git 扩展集合..” 扩展，即真正的软件。 git 上有大部头，我们知道它可以切片，切丁，切丝。但是 SO 上的每个 git-flow Q 都不能用“不知道，没关系，看 git”来解决。一个更好的答案是“你不能这样做并且仍然合理地使用 git-flow”或“使用 git-flow with git 的步骤，没有完全搞砸狗：1,2,3 ,...”
@meagar - 实际上这是对原始问题的一个很好的回答。

【解决方案3】：

我相信如果您想同时支持两个版本的应用程序，最好为此创建两个不同的存储库。

【讨论】：

【解决方案4】：

我意识到这是一个老问题，但我只是找到了一种相当简单的方法来处理它。

在我的开发服务器上，我基本上有两个工作副本，一个用于 v1.0，另一个用于 v2.0。

然后我为 v2.0 创建一个单独的“开发”分支，当我在 2.0 环境中运行“git flow init”时，我将其用作我的“下一个版本”分支。

我相信你可以对 master 分支做同样的事情，但对我来说这已经足够了。

【讨论】：