并行发布线的 Git 分支策略

Question

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

我发现缺少的是同时支持 2 个主要版本。假设我们有 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 来支持这一点。我正在考虑创建 2 个开发分支 - 每个主要版本一个，并不断从开发 1.2 分支合并到开发 2.0。但后来我不知道我应该掌握什么。或者我也应该有 2 个主分支？有什么建议么？

谢谢

Answer 1

由于这个话题可能相当固执己见，我将简单地继续您的疑问：

• 是的，在你的情况下，两个development分支听起来合乎逻辑
• 分支master（在您的情况下是两个）（它们根本不必命名为 master）将始终反映生产就绪状态（如成功的 Git 分支模型中所述）