使用git-flow实现多个开发分支

Question

我目前正在深入研究git-flow，并尝试弄清如何在我参与的项目中使用它。

我已经查看了各种git-flow教程，并且对git非常熟悉。因此，我不需要关于git本身的任何提示，而是需要直接了解使用git-flow的工作流程。

这里是情况：

当我发布一个版本（称为1.0）时，它会从develop分支中分支出来，这很好。现在假设我开始在2.0上工作，添加新功能。当然，一旦完成，我希望将它们合并回develop。现在在1.0上进行热修补也没问题，所以让我们也说我会生成几个版本1.0.1、1.0.2等。所有这些都将更新develop分支，这也很好。到目前为止没有什么麻烦，我可以独立地为2.0开发功能和1.0.x进行热修复。

但是，假设有人要求在1.1发布中添加新功能。现在我有一个问题。如果我创建一个特性分支，这将基于develop分支，而develop可能已经包含2.0的内容，而我可能不希望在此1.1发布中包含这些内容。

有没有简单的方法来单独处理这些2.0和1.1变更？

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

• 在develop上的最后一个发布位置创建一个新分支。将develop变基到此位置并重命名其他develop分支。但是，那么该分支将不包含任何来自1.0.1等的热修复。

• 在2.0完成之前，不要合并回2.0的功能。然而，这样就必须把大量未合并的更改保留到最后一刻。此外，如果先发布2.0，然后请求对1.0.x进行更改，则无法解决问题。

使用git flow是否可能实现这一点？即，在新版本的工作已经开始或甚至已经完成后，基于较早版本进行发布？

- LiKao

---

嗨，Git-Flow现在支持这个功能吗？ - atian25

谷歌“Branch per Feature”。CI群体，特别是Subversion支持者对此表示反感。我的文章是为了辩护它，前提是有正确的工具支持。希望它能帮助人们理解问题的关键所在，特别是与讨论的链接 - 无需Google+账户即可阅读。它已经复制到我网站的单独页面上。 - Adam Dymitruk

Answer 1

有关“git-flow改进”的更多信息：

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

关键是从上一个版本的点开始开发功能。无论您有几个已发布的支持版本都不应该成为问题。

更新：

我已将其重写为博客形式：

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

- Adam Dymitruk

---

我无法在不创建帐户并同意表单的情况下访问Google Plus。是否有博客上的副本？ - drudru

@drudru 您不需要帐户即可查看该链接。 - user229044

git flow feature finish <name> 一直试图与 develop 分支合并，而不是它所工作的基础分支。 - alper

plus.google的链接已经失效，会提示Google+不再向个人用户提供服务的错误信息。 - alper

Answer 2

使用git flow可以实现这个吗？

作为一系列最佳实践而不是硬性规定，使用git-flow可以实现任何事情。只需从您的1.0发布分支而不是您的develop分支打开功能分支即可。

- user229044

---

好的，我的措辞不太好。我不应该使用“可能”的词汇，而应该更像是“容易支持”。让我看看我是否正确理解了你的回答：如果我执行git flow feature start，这个功能会从当前位置分支出来？也就是说，如果我在master上，它将从那里分支出来？因为我观看的教程给人的印象是无论当前检出什么，它都会从develop分支出来。我想那么唯一的问题就是保持主分支处于正确的状态（例如在2.0之后发布1.1时）。 - LiKao

如果你执行 git flow feature start，那么你已经迷失了方向，因为 git-flow 基本上不支持你正在做的事情。你必须使用 git 而不是 git-flow 来实现你想要的功能。检出你的 1.0 分支，然后执行 git checkout -b feature/my-feature。这样你就会有一个以 1.0 为起点的新分支。 - user229044

@michael_n Git-flow首先是一系列最佳实践。有些笨拙的命令行工具并不需要遵循这些最佳实践，事实上，在许多情况下，比如在问题中讨论的情况下，它会阻碍而不是帮助。我的答案解决了如何使用Git-flow，而不是在git-flow CLI上使用特定的命令（这些命令不存在）。 - user229044

“首先是一系列最佳实践”，我认为没有人会反对这个说法，但这只是其中的一半。根据定义（https://github.com/nvie/gitflow/），它还包括“一组Git扩展，提供高级仓库操作。” 扩展，也就是“真正的软件”。Git有大量的文献，我们知道它可以进行各种操作。但是每个关于git-flow的问题都不能简单地通过“不知道，无关紧要，看看git”来解决。一个更好的答案是，“你不能那样做，并且仍然合理地使用git-flow”，或者“使用git-flow的步骤，而不完全搞砸:1,2,3...” - michael

@meagar - 实际上，这是对原问题的非常好的回答。 - michael

Answer 3

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

- Anton

Answer 4

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

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

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

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

- Aaron Lozier