并行发布行的 Git 分支策略

Question

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

我发现缺少的是同时支持 2 个主要版本。假设我们有 2 个平行的主要发行版:1.2.x 和 2.0.x。 1.2 中的所有功能最终都应该在 2.0 中，但不能反过来。 1.2会提前完成，然后需要几个月的支持(bugfixing)。

     > 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 来支持它。我正在考虑创建 2 个开发分支——每个主要版本一个，并不断从开发 1.2 分支 merge 到开发 2.0。但是后来我不知道我应该掌握什么。或者我也应该有 2 个主分支？
有什么建议？

谢谢

Answer 1

由于这个话题可能很自以为是，我将简单地从你的疑惑中继续:

是 两个development分支在您的情况下听起来很合乎逻辑

master分支(在您的情况下为两个)(它们根本不必命名为 master)总是 反射(reflect)生产就绪状态 (如 A successful Git branching model 中所述)