并行发布线的 Git 分支策略答案

【问题标题】：Git branching strategy for parallel release lines并行发布线的 Git 分支策略
【发布时间】：2016-12-06 01:30:45
【问题描述】：

我们是迁移到 Git 的小团队，我想知道我们应该选择哪种分支模型。我已经在网上阅读了很多文章，我发现 here 或 here 描述的 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 个主分支？有什么建议吗？

谢谢

【问题讨论】：

标签： git github bitbucket

【解决方案1】：

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

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

【讨论】：

【解决方案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 和 dev，其中 @987654328 @ 确实）

【讨论】：