我正在制定基于 git 的分支/merge 策略，以满足我的组织的需求: 我引用了GitFlow(链接:https://datasift.github.io/gitflow/IntroducingGitFlow.html)
并开始适应各种场景。这对于使用功能分支的正常开发和使用发布分支的发布都是有好处的。然而，当涉及到修补程序时，事情就会变得复杂。我们的产品的多个不同版本部署到不同的客户端，我们需要能够为所有客户端部署修补程序。 我相信 GitFlow 假设只有最新版本的产品部署在生产中，并且该策略通过在每个版本的主分支上创建标签来满足这一场景。如果需要修补程序，可以从 master 的最后一个标记创建一个新的修补程序分支，并将更改 merge 回 master 和开发中，并从那里继续。然而，就我而言，我可能需要将修补程序部署到比 master 晚几个版本的版本，并且我不能简单地将其 merge 回 master 中。我必须将它 merge 回原来的发布分支和开发分支。我必须跟踪所有发布分支并对它们进行适当的版本控制。
我想知道是否有一个优雅的解决方案来解决这种情况。此外，因为我不再从 master 上的标签中获取修补程序分支并 merge 回 master，所以同时拥有开发分支和 master 分支有什么意义呢？我不需要开发分支。功能分支可以直接 merge 到 master，在发布时，我可以从 master 创建一个发布分支，一旦准备好，就可以将其 merge 回 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
并非如此:需要逐个版本地评估向后移植修补程序(某些版本可能不需要修复)
但是您不需要将其 merge 到开发分支(除非修复仍然与下一个版本相关)，只需 merge 到发布分支即可。
what's the point of having both a develop and a master branch? I don't need the develop branch
master 记录每个新版本(及其所有提交代表一个新版本)。
从每个版本中，可以创建一个发布分支来托管任何演变(例如新的向后移植的修复程序)
关于Git分支/merge 策略: release + hotfix branches, master有什么意义，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51295807/