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 hotfix
branches. 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
.