GIT Flow 和对并行软件版本的支持

Question

我的公司正在切换到 GIT（从 SVN）。

我一直在阅读有关 GIT 流程的文章：

http://nvie.com/posts/a-successful-git-branching-model/

而且我不明白，我如何才能使其适应我们当前的发布架构。

当前版本架构

假设我们公司的公司部门发布软件 X。

我们的团队为软件开发包/模块。

有时，对于不同版本的软件，我们不需要更改任何内容，只需修复轻微的错误 =>请参阅包 2。

有时，公司人员会在某些领域提出许多设计更改，我们必须创建特定于版本的调整（代码、文档或配置）=> 请参阅包 1 或 3。

目前在 SVN 中是如何处理的：

使用主干/分支布局。如果你得到特定版本的东西，比如包 1 中的代码，你会发现一个 V12、V14、V15、V16 和 V16 子目录，其中包含版本特定的更改。我们的发布工具（ANT / Jenkins）处理了这种复杂性。

我的问题：

在 GIT 流程中，发布分支被删除、合并回 master 并标记在那里。

您如何处理旧版本中的错误修复（在我的示例客户端 4 中）？

您如何处理想要获取软件包旧版本（客户端 1 升级计划）的客户？

（在现实生活中，我们有 100 多个包和 20 多个客户端）

我已阅读这些内容，但没有找到问题的答案：

Git-flow and master with multiple parallel release-branches

Git flow: Best practice for dealing with minor releases

Multiple development branches with git-flow

感谢您的帮助

Answer 1

根据您的描述，这就是我所说的支持分支。在我使用的一个名为 GitVersion 的实用程序中，我们在这里描述了这些：

https://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/#support-branches

支持分支在 GitFlow 中并没有真正涵盖，但如果您需要同时维护多个主要版本，那么它是必不可少的。您也可以使用支持分支来支持次要版本。如果您只是支持专业，则将您的分支命名为 support/.x（即 support/1.x），以支持未成年人使用 support/..x 或 support/..0。 （即 support/1.3.x 或 support/1.3.0）