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

Reply via email to