适用于多个活动版本的Git工作流程，同时处理修补程序

我正在尝试选择最适合我们产品的Git工作流程。以下是参数：

• 我们一年会发布一些主要版本，最多可以说10个
• 我们同时有多个版本的产品处于活动状态（有些人使用v10.1，有些人使用v11.2，依此类推）
• 我们需要能够同时处理多个发行版（因此我们可以处理v12.1，但是当我们到达发行版末尾时，我们将同时开始处理v12.2）。
• 发现严重错误后，我们需要能够修复版本

到目前为止，这是我认为它可以工作的方式：

• 使用单个远程仓库
• 从master创建分支12.1
• 根据12.1创建要素分支，提交并合并回12.1，然后按入
• 一旦我们需要开始开发将来的版本，请基于12.1创建一个新的分支12.2。
• 从那时起，在使用12.1的功能时，从12.1创建分支，提交更改，然后合并到12.1和12.2中，
• 如果使用12.2的功能，请从12.2创建分支，提交更改，然后仅合并到12.2，
• 版本12.1完成后，将其合并到master和tag master分支中，并带有12.1
• 如果需要修补程序，请从需要该修补程序的最早的发行分支创建修补程序分支，提交更改，然后合并回该发行版和可能受影响的将来发行版的所有发行分支；如果最新的稳定版本分支受到影响，请将其合并到master。

我有一些担忧：

• 我不确定将修补程序从旧分支合并到新分支是否会很顺利，尤其是在存在许多重叠更改的情况下；在看起来有冲突的情况下，在每个分支中手动进行热修复会更聪明吗？
• 我看到的工作流模型似乎并没有使发行分支保持活跃，一旦完成，发行就被合并到主版本中，被标记并删除了。我的问题是，如果我拥有的只是master中的标签，那么我就不怎么管理发行版的状态，似乎更容易在分支中进行修补，然后有了发行版，我可以随时返回具有最新的修补程序（甚至可以在发行版中标记该修补程序）。不知道有什么办法可以使我回到master内，并以某种方式获取已应用修补程序的发行版副本并更新该标签。

考虑到我已经指定的要求，我对我可能忽略的事情或完成事情的更好方法表示了赞赏。

您似乎正在分支到每个主要发行版（12.0.0），然后可能对每个主要发行版（12.1.0）和热修复程序（12.2.1）进行次要更新。正确？

没有特定的原因可以使您在发布发布后无法在GitFlow中保持发布分支的活动，除了任何模型都很难长时间协调多个分支之间的更改这一事实。我想GitFlow也针对在开发下一个实时发布时保持单一实时发布的产品进行了更多建模。

我会坚持使用GitFlow并进行一些修改。

跳过主分支。到目前为止，我还没有实际使用它，并且它将失去您工作方式的线性。在开发的下一个主要版本上继续开发。如果您决定保留母版，则不要在母版上放置发行标签，而应将它们放在发行分支的最后一个提交上，该分支会生成要运送的二进制文件。

将它们合并回开发之后，不要丢弃发行分支。而是保留它们以备下一个次要发行版以及可能的修补程序。如果您停止支持发行版，那么我认为可以删除它们。您可以在其主要组件release / 12之后命名release分支，然后从其分支中创建sub-release分支release / 12.1，release / 12.2。我不必太担心这种并行性级别，但这可能就是我会尝试的方法。在这种情况下，您可以将每个主要发行分支视为自己的子GitFlow环境。

如果您必须同时并行处理多个未来主要发行版的功能，那么也许您必须在开发中保留下一个（13），而在其他“ develop-N”分支上保留较高版本的任何内容（14、15）。 。一般而言，这似乎很难维持，但有可能。

似乎您的主要问题（“我们需要能够同时处理多个发行版[]]）的可能解决方案是git worktree add <path> [<branch>]

一个git仓库可以支持多个工作树，从而允许您一次签出多个分支。
使用git worktree add，新的工作树与存储库关联。

与“ git init”或“ git clone” 准备的“主工作树”相对，该新工作树称为“链接工作树”。
一个存储库有一个主工作树（如果不是裸存储库）和零个或多个链接的工作树。

有关的详细介绍，请参见此SO答案git worktree。

您提到您熟悉gitflow。我建议为您的方案添加它。您将需要从开发分支中创建分支以支持较旧的版本。这些较旧的版本还需要具有自己的发行版/主分支和修补程序分支。您将需要定期将支持分支合并到较新的支持分支和开发分支中。

随着主要版本的发展分歧，这将越来越难。没有银弹。有时，手动进行更改会更容易。维护旧版本的成本将增加，并且在某些时候将不再值得。

这完全取决于您在旧版本中进行的更改。如果只是错误修正，那就比较容易合并。如果您尝试添加新功能，那将很难。