Git Braching/Merging 攻略：release + hotfix branches，master有什么意义
Git Braching/Merging strategy: release + hotfix branches, what's the point of master
我正在研究基于 git 的 branching/merging 策略，以满足我的组织的需求：
我提到了 GitFlow(link: https://datasift.github.io/gitflow/IntroducingGitFlow.html)
并开始适应各种场景。这对于使用功能分支的正常开发和使用发布分支的发布都是有好处的。但是，当涉及到修补程序时，它会变得复杂。我们产品的几个不同版本被部署到各种客户端，我们需要能够为所有客户端部署修补程序。
我相信 GitFlow 假设只有最新版本的产品部署在生产环境中，并且该策略通过在主分支上为每个版本创建标签来迎合这种情况。如果需要修补程序，可以从 master 的最后一个标记创建一个新的修补程序分支，并将更改合并回 master 和 develop 并从那里继续。但是，就我而言，我可能需要将修补程序部署到比 master 晚几个版本的版本，我不能简单地将它合并回 master。我必须将它合并回原来的发布分支和开发分支。我必须跟踪所有发布分支并适当地对它们进行版本控制。
我想知道是否有一个优雅的解决方案来解决这种情况。此外，因为我不再从 master 上的标签中获取一个修补程序分支并合并回 master，所以同时拥有开发分支和主分支有什么意义呢？我不需要开发分支。功能分支可以直接合并到 master，在发布时，我可以从 master 创建一个发布分支，一旦准备好，就可以将它合并回 master。有什么建议吗？
与 mentioned here 一样，Gitflow 非常适合具有预定发布周期的项目。
Develop and Master Branches
Instead of a single master branch, this workflow uses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features. It's also convenient to tag all commits in the master branch with a version number.
所以：
I have to merge it back to the original release branch and develop branch. I have to keep track of all the release branches and version them appropriately.
I am wondering if there is an elegant solution to this situation
并非如此：向后移植修补程序需要在逐个版本的基础上进行评估（某些版本可能不需要修复）
但是你不需要将它合并到开发分支（除非修复仍然与下一个版本相关），只需合并到发布分支。
what's the point of having both a develop and a master branch? I don't need the develop branch
master 记录每个新版本（及其所有提交代表一个新版本）。
从每个版本中，可以创建一个发布分支来承载任何演变（比如一个新的向后移植的修复）
我正在研究基于 git 的 branching/merging 策略，以满足我的组织的需求： 我提到了 GitFlow(link: https://datasift.github.io/gitflow/IntroducingGitFlow.html)
并开始适应各种场景。这对于使用功能分支的正常开发和使用发布分支的发布都是有好处的。但是，当涉及到修补程序时，它会变得复杂。我们产品的几个不同版本被部署到各种客户端，我们需要能够为所有客户端部署修补程序。 我相信 GitFlow 假设只有最新版本的产品部署在生产环境中，并且该策略通过在主分支上为每个版本创建标签来迎合这种情况。如果需要修补程序，可以从 master 的最后一个标记创建一个新的修补程序分支，并将更改合并回 master 和 develop 并从那里继续。但是，就我而言，我可能需要将修补程序部署到比 master 晚几个版本的版本，我不能简单地将它合并回 master。我必须将它合并回原来的发布分支和开发分支。我必须跟踪所有发布分支并适当地对它们进行版本控制。
我想知道是否有一个优雅的解决方案来解决这种情况。此外，因为我不再从 master 上的标签中获取一个修补程序分支并合并回 master，所以同时拥有开发分支和主分支有什么意义呢？我不需要开发分支。功能分支可以直接合并到 master，在发布时，我可以从 master 创建一个发布分支，一旦准备好，就可以将它合并回 master。有什么建议吗？
与 mentioned here 一样，Gitflow 非常适合具有预定发布周期的项目。
Develop and Master Branches
Instead of a single master branch, this workflow uses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features. It's also convenient to tag all commits in the master branch with a version number.
所以：
I have to merge it back to the original release branch and develop branch. I have to keep track of all the release branches and version them appropriately.
I am wondering if there is an elegant solution to this situation
并非如此：向后移植修补程序需要在逐个版本的基础上进行评估（某些版本可能不需要修复）
但是你不需要将它合并到开发分支（除非修复仍然与下一个版本相关），只需合并到发布分支。
what's the point of having both a develop and a master branch? I don't need the develop branch
master 记录每个新版本（及其所有提交代表一个新版本）。
从每个版本中，可以创建一个发布分支来承载任何演变（比如一个新的向后移植的修复）