> I think what you are looking for is how my 'maint' and 'master' > branches are maintained; 'maint' corresponds to your "stable > release" while 'master' corresponds to your "develment branch". > > When a stable release is cut, 'maint' is forked from there. > > Truly obvious corrections will be applied on top of the tip of > 'maint' directly, while if there are any doubt about a proposed > change I might fork a topic off of the tip of 'maint' and cook > the fix for a while until I finally merge it to 'maint'. This > way, 'maint' will be "bugfix only since the last release". > > The tip of 'maint' will be merged into 'master', from time to > time, to make sure that all fixes will be in 'master'. > > When it is time for a new release to be cut, I'd make sure that > the tip of 'maint' is merged into 'master' (it usually is) and > then the tip of the 'master' is tagged to be released. After a > release is made, I could have two maintenance branches (one that > continues on top of the old codebase, another that fixes the new > release). A fix that can apply to both codebases will be > applied to the maintenance branch for the old release and then > its tip can be pulled into the maintenance branch for the new > release and then its tip can further be merged into the > development branch. > > At some point, the codebases for the older release and the > current release become diverged enough that merging could become > inpractical (the same bug may need different fix if the > infrastracture has become different); you would need to bite the > bullet and fix it twice (i.e. differently). Thanks for detailed description. As a cunclusion I would like to say: all bug fixes are made in the stable branch and then stable branch will be merged to development branch. That is easy ! - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html