如何在维护多个主要版本的项目上有效使用git-flow？

我已经将我的几个项目迁移到git flow工作流程中，并且我很喜欢它。但是，我还没有找到一种最佳实践来使一个项目同时维护一个以上的主要版本，从而使事情顺利进行。

具体来说，我不是在维护“免费版本”和“付费版本”或任何其他并行模型，我是在谈论一个项目，其中发布了版本1，并且仍支持次要版本（1.1、1.2等）。），直到发布了第3版为止，此时将维持第2和第3版，直到第4版发布为止。

您如何或将如何在gitflow工作流程中一次维护一个项目的两个或多个受支持版本？

git workflows gitflow

— 对冲法师
source

没有任何atm示例，但是我所知道的项目针对不同的主要版本使用了单独的存储库，并将移植补丁从一个移植到另一个。

— ProdigySim 2011年

@ProdigySim：感谢您提供数据点，但是仅仅是我还是会增加一定数量的跟踪和管理开销？

— HedgeMage 2011年

@ProdigySim我怀疑那些项目没有使用具有git分支和合并功能的工具。

— Rein Henrichs

@Rein他们使用Mercurial。我认为，在跟踪软件的并行主要版本方面，分支不是很干净。

— ProdigySim 2011年

然后我的猜想是正确的。是的，如果您的工具正确支持它，那将非常干净。git和Linux内核都采用这种方式。

— Rein Henrichs

Answers:

man gitworkflows是git flow工作流程的祖父，描述了git工作流程的一般准则；使用pu，next，master和maint分支机构; 以及如何maint管理。如果你有多个分支机构的维护，可以为它们命名，例如maint/1.x，maint/2.x等等。

关键不在于如何使用git命令，而是如何构建合理的过程。确定哪些事情对您很重要（易于向后移植？），并构建（和记录）满足这些约束的工作流程。

— 雷恩·亨里斯（Rein Henrichs）
source

但这能回答问题吗？也就是说，git-flow是否支持问题中描述的灵活发行模型，还是会恢复为基本的git命令？（“ gitworkflows”描述了基本git工作流的用法，即git前的流程。）创建了Git-flow（表面上）来简化git合并/分支过程，因此团队（具有不同程度的git-fu实力）可以专注于编码和避免费时的“错误合并”错误。是否可以使用git-flow与v2.5。{1,2,3，...}同时维护和开发v1.2。{1,2,3，..}？也许有长期发行分支？还是master1，master2，...？

— 迈克尔2012年

基本上，你会复制master，release以及develop分支机构为您维护每一个主要版本。它们之间的交互方式保持不变。对于feature分支，只需确保从打算合并回的最旧分支开始分支，以防止引入不需要的依赖项。然后，当您合并feature分支时，只需对每个适当的较新的主要版本分支进行其他合并。

— 卡尔·比勒费尔特
source

掌握所有发行版本不是全部内容吗？

— HedgeMage

@HedgeMage，确实是在更线性的发布周期中，但是对于并行主要版本而言，这是非常不切实际的。

— Karl Bielefeldt

这似乎是最实用的解决方案，除非有一些使用修补程序的可靠尝试或我不知道的方法。我一直在寻找一种引入git-flow的方法，并且仍然能够（作为一个不幸的前提）保持我们现有的发行模型，在该模型中，我们必须维护/开发较旧的发行版（而不仅仅是修补程序）。因此，v5.1.x会在v6.1.x发行后的几年内继续存在（添加新功能，修复错误等）。在任何给定时间支持和开发大约2-3个主要版本。但是，必须将错误修复程序应用于存在该错误的每个版本。

— 迈克尔2012年