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

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