Question

我们是小团队迁移到Git，我想知道我们应该选择哪种分支模型。我在线阅读了很多文章，但我发现，here或here描述的Gitflow，即使通常看起来很好，也可能无法完全满足需求。

我发现缺少的是同时支持2个主要版本。假设我们有两个并行的主要版本行：1.2.x和2.0.x. 1.2中的所有功能最终应该是2.0，但不是相反。 1.2将提前完成，然后需要支持几个月（错误修正）。

     > 1.2 features here  |> only bugfixes from now
          1.2.5  1.2.6  1.2.7   1.2.8  1.2.9 (end)
1.2.x ------o------o------O-------o------o
             \      \      \       \      \ (merge after every release)
        2.0.x \--------o----------o----------o----------o------->
                      2.0.1     2.0.1      2.0.2
                2.0 specific features

我想知道如何修改Gitflow来支持它。我正在考虑创建两个开发分支 - 每个主要版本一个，并继续从开发1.2分支到开发2.0。但后来我不知道应该掌握什么。或者我应该有2个主分支？有什么建议吗？

由于

Answer 1

由于这个话题可能非常自以为是，我会简单地从你的想法中继续：

是两个development分支听起来合乎逻辑
master分支（在您的情况下为两个）（它们根本不必命名为master）将始终反映生产就绪状态（如描述在A successful Git branching model ）

Answer 2

1.2中的所有功能最终应该是2.0，但不是相反。 1.2将提前完成，然后需要支持几个月（错误修正）。

gitflow以发布为中心这一事实并不妨碍您随时将1.2修补程序分支合并到dev或2.0发布分支。这可能不是gitflow命令，但仍然是基本的git merge命令。

我正在考虑创建2个开发分支

一旦你有一个1.2修补程序分支（在gitflow hotfix start之后），你可以继续制作修补程序，并将它们合并到任何其他分支，如2.0版本（除了master和{{1 } {，dev确实如此）

并行释放线的Git分支策略

2 个答案: