GIT并行软件版本的流程和支持
GIT Flow and support of parallel software versions
我的公司正在切换到 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
感谢您的帮助
根据您的描述，这就是我所说的支持分支。在我使用的名为 GitVersion 的实用程序中，我们在这里描述了这些：
Support branches are not really covered in GitFlow, but are essential if you need to maintain multiple major versions at the same time. You could use support branches for supporting minor releases as well. If you are just supporting the majors, then name your branch support/.x (i.e support/1.x), to support minors use support/..x or support/..0. (i.e support/1.3.x or support/1.3.0)
我的公司正在切换到 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
感谢您的帮助
根据您的描述，这就是我所说的支持分支。在我使用的名为 GitVersion 的实用程序中，我们在这里描述了这些：
Support branches are not really covered in GitFlow, but are essential if you need to maintain multiple major versions at the same time. You could use support branches for supporting minor releases as well. If you are just supporting the majors, then name your branch support/.x (i.e support/1.x), to support minors use support/..x or support/..0. (i.e support/1.3.x or support/1.3.0)