具有多个并行发布分支的 Git-flow 和 master

Git-flow and master with multiple parallel release-branches

提问by Mot

We are trying to adopt the successful Git branching modelimplemented 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 masterand tagged there. Why not tag the releases in their release branches? Why the masterat all? Or why a developbranch and not use masterfor it?

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

采纳答案by mstrap

In the git-flow model, your "latest released" version actually maps to the master, while your "preview release" maps to a git-flow releasebranch. It is forked from developand finally merged into masterwhen 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 masteralways represents the most stable state of your latest released version.

在 git-flow 模型中，您的“最新发布”版本实际上映射到master，而您的“预览版本”映射到 git-flowrelease分支。它在实际发布发生时分叉develop并最终合并master。然后这将成为您的“最新版本”，并且您通常只会使用 git-flowhotfix分支修复该版本的错误。这样，您的master始终代表最新发布版本的最稳定状态。

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

如果您想修复旧版本的错误或在那里进行任何其他开发，您将从support适当的提交中分叉一个分支master（您将在那里创建所有版本）。support分支仍然是实验性的（根据文档）并且没有很好的记录。但正如您从命令行帮助中看到的：

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 masternor 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 masterand develop), just start a hotfix, cherry-pick your changes and finish the hotfix.

这些分支刚刚启动，并不打算合并回masternor develop。这通常很好，因为对“古老”版本的修复或客户要求在“古老”版本中实现的功能不能或不应该回到master. 如果您仍然认为，您想将修复程序移植到您的主要开发线（由master和表示develop），只需启动一个hotfix，挑选您的更改并完成hotfix.

回答by Sarien

Looks like mostly a mental model with a bit too much emphasis on branches. I agree, you could just tag the commits you release instead of merging them back into master.

看起来主要是一种心理模型，有点过分强调分支。我同意，您可以只标记您发布的提交，而不是将它们合并回 master。

The picture is pretty, though. Merging everything back into master gives a clear indication of the releases in temporal order instead of having version tags strewn all over the graph.

不过画面挺好看的 将所有内容合并回 master 可以按时间顺序清楚地指示版本，而不是在整个图表中散布版本标签。

I think this model does not work for bugfixing in older releases, though. It messes up the neat ordering.

不过，我认为此模型不适用于旧版本中的错误修复。它弄乱了整洁的顺序。

1. Say we have released Version 1.0.1 and later added features and released 1.1.0.
2. We discover a bug in 1.0.1 and want to fix it in both version
3. We have to add 1.0.2 after 1.1.0 in master and then directly atfer (or before) also 1.1.1.

1. 假设我们发布了 1.0.1 版，后来添加了功能并发布了 1.1.0。
2. 我们在 1.0.1 中发现了一个错误，并希望在两个版本中修复它
3. 我们必须在 master 中的 1.1.0 之后添加 1.0.2，然后直接添加（或之前）1.1.1。

To answer your question: I think this is a set of rules that makes for a simple mental model in some cases. Not all of the rules make sense from a purely technical point of view but that doesn't make them bad. Mental models be good for 'em humanses.

回答你的问题：我认为这是一套规则，在某些情况下可以建立一个简单的心智模型。从纯粹的技术角度来看，并非所有规则都有意义，但这并不会使它们变得糟糕。心智模型对人类有益。

回答by Haralan Dobrev

I personally think the mentioned git-flow is overcomplicated.

我个人认为提到的 git-flow 过于复杂。

If you are using GitHub try the GitHub flow(as described by Scott Chacon).

如果您正在使用 GitHub，请尝试GitHub flow（如 Scott Chacon 所述）。

It is especially useful for collaboration on multiple features, code-review and you could combine it with your Continuous Integration solution using the Commit Status API.

它对于多个功能的协作、代码特别有用，您可以使用Commit Status API.

UPDATE: There is a new official website of The GitHub Flow?

更新：有一个新的 GitHub Flow 官方网站？

UPDATE 2: There is a new official (and simplified) GitHub Guide for The GitHub Flow?: https://guides.github.com/introduction/flow/

更新 2：GitHub Flow 有一个新的官方（和简化）GitHub 指南？：https: //guides.github.com/introduction/flow/

回答by vaheeds

In my case, I have two version of the same software that the basics are the same but each version has some different features.

就我而言，我有两个版本的相同软件，它们的基础知识相同，但每个版本都有一些不同的功能。

So I create two worktreethat means, create two relevant long-running branches beside the master.

所以我创建了两个worktree，这意味着在 master 旁边创建两个相关的长期运行的分支。

$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master

Then I have:

然后我有：

$git branch
master  # base stuff here
version-silver # some normal features
version-gold # some better features

There is one repository, but I have 3 separate folders beside each other for each branch above. And make the common changes in master. then merge it with both other versions.

有一个存储库，但对于上面的每个分支，我都有 3 个单独的文件夹。并在 master 中进行通用更改。然后将其与其他两个版本合并。

cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here i get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here i get the basic.cpp latest changes for gold project

Specific changes of each version will go in the corresponding folder as well, and the works on each project are isolated and IDE wouldn't be confused.

每个版本的具体变化也会放在对应的文件夹中，每个项目的作品都是独立的，IDE不会混淆。

Hope that helps.

希望有帮助。

回答by mdn

Totally agree with @Mot.

完全同意@Mot。

It's nice to hear the same questions.

很高兴听到同样的问题。

Our team was also hunted for more Universal branching model than Successfullone. I.e. as @Mot mentioned above - the main idea is to avoid introducing extra repositories for supporting release-* branches in separate *.git repo as it for example is done by kernel.org for stable releases. But kernel.org does it for the sake of minimalizing of downloaded sizes I guess.

我们的团队还寻找比Successful更通用的分支模型。即如上面提到的@Mot - 主要思想是避免在单独的 *.git repo 中引入额外的存储库来支持 release-* 分支，因为它例如由 kernel.org 完成以实现稳定版本。但我猜 kernel.org 这样做是为了最小化下载的大小。

For me it seems that it's more clean to have masteras mainline for develop.

对我来说，让master作为develop 的主线似乎更干净。

Also there are some conflicts in release-* merging modelto masterand tagging it afterwards with idea to

在release-* 合并模型中也有一些冲突来掌握并在之后用想法标记它

use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master

每次在 master 上有提交时，使用 Git 钩子脚本自动构建和推出我们的软件到我们的生产服务器

cause finishing (merging and tagging)is not a atomic transaction :

导致整理（合并和标记）不是原子事务：

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

and if git hook start build with automative versioning support:

如果 git hook 开始构建具有自动版本控制支持：

$git describe --tags --long >.ver

then a mistaken version is possible to be built for:

那么可能会构建一个错误的版本：

$ git merge --no-ff release-1.2

I know that versioning in Successfullone introduces some bump-version processbut it's not automatic.

我知道Successfulone中的版本控制引入了一些bump-version 过程，但它不是自动的。

So to sum - the key differences we introduce to branch model for releases-* merging and tagging are: - tagging release on Creating its branch - keep release's branch to enable maintainance them in future

总而言之 - 我们为发布 - * 合并和标记引入分支模型的主要区别是： - 在创建其分支时标记发布 - 保留发布的分支以便将来对其进行维护

回答by Bernie Lenz

The master branch should ALWAYS represent your production code base, hence you always merge the code back to master right after a production release.

master 分支应该始终代表您的生产代码库，因此您总是在生产版本发布后立即将代码合并回 master。

Tagging is used to "memorize" the exact code which went into a production release so you can go back later and analyze the code if something went wrong.

标记用于“记住”进入生产版本的确切代码，以便您可以稍后返回并在出现问题时分析代码。

With this theoretically it shouldn't matter if you tag your code on the release branch or on the master branch after you merged back to master. I personally prefer to tag the code on the release branch as this is exactly the code that went into the build/release (assuming something can go wrong with the merge).

从理论上讲，在您合并回 master 之后，是在发布分支还是在 master 分支上标记代码应该无关紧要。我个人更喜欢在发布分支上标记代码，因为这正是进入构建/发布的代码（假设合并可能会出错）。

The issue with the development branch concept is that it is single threaded. Brendan in this thread mentioned a strategy which could be used involving a development branch concept.

开发分支概念的问题在于它是单线程的。Brendan 在这个线程中提到了一个可以使用的涉及开发分支概念的策略。