View mode: basic / threaded / horizontal-split · Log in · Help
July 29, 2012
A successful Git branching model
Have you seen this? What do you think of it? Maybe we'll use this model
in our company in nearest future.

http://nvie.com/posts/a-successful-git-branching-model/
July 29, 2012
Re: A successful Git branching model
On Sunday, 29 July 2012 at 20:24:42 UTC, mta`chrono wrote:
> Have you seen this? What do you think of it? Maybe we'll use 
> this model
> in our company in nearest future.
>
> http://nvie.com/posts/a-successful-git-branching-model/

I use it every day at work and love it. I've shared it a couple 
of times on this NG but it doesn't seem to attract much attention.

Regards,
Brad Anderson
July 29, 2012
Re: A successful Git branching model
On 07/29/12 22:36, Brad Anderson wrote:
> I use it every day at work and love it.

+1
July 30, 2012
Re: A successful Git branching model
On Sun, 2012-07-29 at 22:36 +0200, Brad Anderson wrote:
> On Sunday, 29 July 2012 at 20:24:42 UTC, mta`chrono wrote:
> > Have you seen this? What do you think of it? Maybe we'll use 
> > this model
> > in our company in nearest future.
> >
> > http://nvie.com/posts/a-successful-git-branching-model/
> 
> I use it every day at work and love it. I've shared it a couple 
> of times on this NG but it doesn't seem to attract much attention.

I don't really see the advantage of separating develop and master.

And personally I am not a great fan of having feature branches in the
mainline repository.

There is a lot about the document and the ideas that are good, but I
don't follow the whole model. For me master is the development branch –
and if using continuous delivery can always be branched and released.
All major and minor releases have separate maintenance branches. with
bugfix releases being tags on that.  This seems enough, I am not sure of
the usefulness of anything more complex. But I may be missing something.
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
July 30, 2012
Re: A successful Git branching model
On 2012-07-29 22:24, mta`chrono wrote:
> Have you seen this? What do you think of it? Maybe we'll use this model
> in our company in nearest future.
>
> http://nvie.com/posts/a-successful-git-branching-model/
>

Yes, please. We badly need at least something better than we have now. 
Don't know if it exactly need to be this model, but something needs to 
change.

-- 
/Jacob Carlborg
July 30, 2012
Re: A successful Git branching model
On Sun, Jul 29, 2012 at 11:53 PM, Russel Winder <russel@winder.org.uk>wrote:

> I don't really see the advantage of separating develop and master.
>
>
master isn't strictly necessary since everything is tagged anyway.  It just
serves as a nice way to see the current release's source code (a pointer to
the latest release). You could just use "master" in place of "develop" and
have a "production" branch fill the role that "master" does in this model
just as easily.


> And personally I am not a great fan of having feature branches in the
> mainline repository.
>
>
They aren't in this model. If you need to share a feature branch with
someone else prior to a pull request they can just pull from your branch on
GitHub directly.


> There is a lot about the document and the ideas that are good, but I
> don't follow the whole model. For me master is the development branch –
> and if using continuous delivery can always be branched and released.
> All major and minor releases have separate maintenance branches. with
> bugfix releases being tags on that.  This seems enough, I am not sure of
> the usefulness of anything more complex. But I may be missing something.
>

It can be modified to fit whatever the need is, of course, but there is a
lot of value in how well it is documented.  Any changes made or alternative
models used should be well documented too to lower the barrier to entry for
contributors. Everyone needs to be working from the same mental model.

Regards,
Brad Anderson
Top | Discussion index | About this forum | D home