并行发布行的Git分支策略

我们正在迁移到Git的小团队，我在想我们应该选择哪个分支模型。我在网上阅读了很多文章，我发现Gitflow如描述的here或here，即使一般看起来不错，也可能不能完全满足需求。并行发布行的Git分支策略

我发现缺少的是同时支持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个主分支？有什么建议吗？

感谢

来源

2016-08-01 Marek

如本主题可能很自以为是从你wonderings我会简单继续：

是分支在你的情况听起来合乎逻辑

的master分支（二在你的情况下）（他们根本不必被称为主人）总是会反映生产就绪状态（就像中所述）

来源

2016-08-01 06:46:44 AnimiVulpis

1.2所有功能应该是最终在2.0，而不是倒过来。 1.2会提前完成，然后需要支持几个月（错误修复）。

事实上，gitflow是发布中心并不妨碍你在任何时间1.2 hotfix分支合并到dev或2.0发布分支。这可能不是gitflow命令，但仍然是基本的git merge之一。

我想创建2个开发分支

一旦你有一个1.2的修补程序分公司（gitflow hotfix start后），你可以不断的修补程序，并把它们合并到任何其他分支一样的2.0版本（另外master和dev，其中git flow hotfix finish确实）

来源

2016-08-01 06:48:55 VonC

并行发布行的Git分支策略

回答

相关问题