具有多个并行版本分支的Git-flow和master [英] Git-flow and master with multiple parallel release-branches

问题描述

我们正在尝试采用成功的Git分支模型通过git-flow。现在，我们正在开发至少两个发布分支，一个用于最新的稳定版本，另一个用于下一个（预览）版本。我不明白的是为什么所有发布版本似乎都线性化到了 master 并在那里进行了标记。为什么不在发布分支中标记发布？为什么主人呢？或者为什么开发分支而不使用 master ？

>在git-flow模型中，您的最新发布版本实际上映射到 master ，而您的预览版本映射到git-flow 释放分支。它是从 develop 分支的，并且最终在实际发布时合并到 master 中。然后这将成为你的最新版本，你通常会使用git-flow hotfix 分支修复该版本的bug。通过这种方式，您的 master 总是表示最新发布版本的最稳定状态。

如果您想要修复旧版本的bug或做其他任何开发，您将从 master 中的相应提交中分支支持 （您将在此处创建所有版本）。 支持分行仍然是实验性的（根据文档，）并没有很好的记录。但你可以从命令行帮助中看到：

 用法：git flow support [list] [-v] 
 git flow support start [-F]< version> <基地> 
  

这些分支刚刚启动，不打算合并回 master 也不是开发。这通常很好，因为客户要求在古代版本中实施的古代版本或功能的修复不能或不应该回到 master 中。如果您仍然认为，您希望将修补程序移植到您的主开发线（由 master 和 develop 表示），只需启动修补程序，樱桃挑选您的更改并完成修补程序。

We are trying to adopt the successful Git branching model implemented by git-flow. Now, we are working on at least two release-branches, one for the latest stable release and one for the next ("preview") release. What I don't understand is why all releases seems to "linearized" to the master and tagged there. Why not tag the releases in their release branches? Why the master at all? Or why a develop branch and not use master for it?

解决方案

In the git-flow model, your "latest released" version actually maps to the master, while your "preview release" maps to a git-flow release branch. It is forked from develop and finally merged into master when the actual release happens. Then this will become your "latest release" and you will usually fix only bugs for that release, using git-flow hotfixbranches. In this way, your master always represents the most stable state of your latest released version.

If you want to fix bugs for older releases or do any other develop there, you will fork a support branch from the appropriate commit in master (you will have all versions ever created there). support branches are still experimental (according to the docs) and are not well documented. But as you can see from the command line help:

usage: git flow support [list] [-v]
       git flow support start [-F] <version> <base>

these branches are just started and not intended to be merged back to master nor develop. This is usually fine, as fixes to "ancient" releases or features requested by customers to be implemented in "ancient" releases can't or should not go back into master. If you still think, you want to port a fix to your main development line (represented by master and develop), just start a hotfix, cherry-pick your changes and finish the hotfix.

这篇关于具有多个并行版本分支的Git-flow和master的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！