Git合并/合并策略：发行版+修补程序分支，主要目的是什么

Question

我正在研究一种基于git的分支/合并策略，该策略可以满足我的组织的需求： 我提到了GitFlow（link：https://datasift.github.io/gitflow/IntroducingGitFlow.html）

，并开始适应各种情况。这对于使用功能分支进行常规开发以及使用发行分支进行发行都是有益的。但是，涉及到修补程序时，它变得很复杂。我们的产品的几种不同版本已部署到各种客户端，我们需要能够为所有客户端部署修补程序。 我相信GitFlow假设仅在生产中部署了最新版本的产品，并且该策略通过在每个版本的master分支上创建标签来满足这一情况。如果需要修补程序，则可以从master的最后一个标记创建一个新的hotfix分支，并将更改合并回master和develop中，然后从那里继续。但是，就我而言，我可能需要将修补程序部署到比master落后多个版本的版本，而我不能简单地将其重新合并到master中。我必须将其合并回原始发行分支并开发分支。我必须跟踪所有发行分支并对其进行适当版本控制。

我想知道这种情况是否有一个优雅的解决方案。而且，因为我不再从master上的标签中获取修补程序分支并合并回master，所以同时拥有development和master分支有什么意义？我不需要开发分支。功能分支可以直接合并到master，在发布时，我可以从master创建发布分支，一旦准备好，就可以将其合并回master。有什么建议吗？

Answer 1

与mentioned here一样，Gitflow非常适合具有预定发布周期的项目。

  

开发和掌握分支机构

  

此工作流使用两个分支而不是单个主分支来记录项目的历史记录。 master分支存储正式的发布历史记录，develop分支充当功能的集成分支。用版本号标记master分支中的所有提交也很方便。

所以：

  

我必须将其合并回原始发行分支并开发分支。我必须跟踪所有发行分支并对其进行适当版本控制。

     

我想知道对于这种情况是否有一个优雅的解决方案

并非如此：向后移植修补程序需要逐个发行版进行评估（某些发行版可能不需要修复）
但是您不需要将其合并到一个develop分支（除非该修补程序与下一个版本仍然相关），而只需将其合并到一个release分支。

  

同时拥有开发分支和主分支有什么意义？我不需要开发分支

master记录每个新版本（所有提交都代表一个新版本）。
从每个发行版中，都可以创建一个发行分支来托管任何演变（例如新的向后移植的修订）