Git-flow and master with multiple parallel release-branches

Question

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 an

Answer 1

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.

Answer 2

Totally agree with @Mot.

It's nice to hear the same questions.

Our team was also hunted for more Universal branching model than Successfull one. 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.

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

Also there are some conflicts in release-* merging model to master and tagging it afterwards with idea to

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

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 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 Successfull one introduces some bump-version process but it's not automatic.

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

Answer 3

I personally think the mentioned git-flow is overcomplicated.

If you are using GitHub try the GitHub flow (as described by 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.

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

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

Answer 4

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

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).

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.

Answer 5

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 worktree that means, create two relevant long-running branches beside the 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.

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.

Hope that helps.

Answer 6

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.

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.

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.

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.