Git-flow and master with multiple parallel release-branches -


we trying adopt successful git branching model implemented git-flow. now, working on @ least 2 release-branches, 1 latest stable release , 1 next ("preview") release. don't understand why releases seems "linearized" master , tagged there. why not tag releases in release branches? why master @ all? or why develop branch , not use master it?

in git-flow model, "latest released" version maps master, while "preview release" maps git-flow release branch. forked develop , merged master when actual release happens. become "latest release" , fix bugs release, using git-flow hotfixbranches. in way, master represents stable state of latest released version.

if want fix bugs older releases or other develop there, fork support branch appropriate commit in master (you have all versions ever created there). support branches still experimental (according docs) , not documented. can see command line help:

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

these branches started , not intended merged master nor develop. fine, fixes "ancient" releases or features requested customers implemented in "ancient" releases can't or should not go master. if still think, want port fix main development line (represented master , develop), start hotfix, cherry-pick changes , finish hotfix.


Comments

Popular posts from this blog

Change php variable from jquery value using ajax (same page) -

Pull out data related to my apps from Android Play Store and iOS App Store -

How can I fetch data from a web server in an android application? -