And another thank you: <quote> Long-running release branches for long-term support
What are the main long-running branches in this model? We have a master branch – which in Subversion (SVN) terms you would call trunk – that is stable-ish. It is in a alpha/RC state. We have stable release branches for each product release we have to ship updates to. Commits always are merged upwards from older to newer branches. If a fix needs to be applied to stable branch 2.2 for example, a bug fix branch is created off the stable branch. First it gets merged back to that branch, and then that branch is merged upwards towards master. These chains of merges can be several branches long, but this operation is almost completely automated. </quote> I think this most resembles what we want (source: the link about atlassian stash from http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows/) Daan On Fri, Aug 8, 2014 at 9:46 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > thanks Rohit, > > I had missed this one. It contains obligatory release management > knowledge for every keyboard toucher that is allowed to use git: > https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html > > I think if we all read this and then study a bit we don't need to > discuss or branching model. It will become clear that we are in fact > doing almost fine and need only small changes. > > -- > Daan -- Daan