Branching strategy for git

[Geert Janssens]

On Wednesday 26 March 2014 12:53:36 Derek Atkins wrote:
> John Ralls <jralls at ceridwen.us> writes:
> > It will be. When we’re ready to release 2.8, the ‘maint’ branch will
> > be renamed to ‘2.6’; when we release 2.8.3, we’ll create a new
> > ‘maint’ branch from ‘master’. We could even do that at 2.8.0,
> > because merging ‘maint’ into ‘master’ isn’t a big deal until
> > ‘master’
> > diverges. Waiting is a hold-over from SVN, which until 1.7 didn’t
> > allow that.
> > 
> > Why not call it ‘2.6’ right away? Just to make maintaining the wiki
> > easier: If ‘maint’ is always the current bug-fix branch, then the
> > policy can say that and not have to be changed every 3 years.
> 
> I guess I didn't realize (or contemplate) we could easily rename the
> branch later -- but I suppose that makes sense based on the way that
> git handles branches.
> 
'Renaming' is a fairly glossy term for what will happen exactly.

> I'm mostly just thinking about way way way down the road someone
> wanting to come back and see the work done on e.g. the 2.6 maint
> branch, when "maint" isn't 2.6 anymore.
> 
At that point there will be a 2.6 branch that took over from maint right before maint was 
aligned with 2.8.

In simplified ascii art -

Right before the first 2.8 release:

A - B - C - E -    (master)
  \   /
    D     -   -    (maint)

Note here that all of the changes on the maint branch get merged into master. This follows from 
the premise that bugfixes are done on the oldest branch that needs them and merged upwards 
into master (or more recent stable branches if there are any).

Releasing 2.8 would simply mean tagging commit E with the 2.8.0 release tag. I won't add it 
here as it's difficult to represent in ascii. But after that the following branch structure will be set 
up:

A - B - C - E -    (master, maint)
  \   /
    D     -   -    (maint-2.6)

And further development happens from there. Bugfixes that still have to be applied to 2.6 will 
be done on the maint-2.6 branch and merged upwards again into maint and master, bugfixes 
that should go into 2.8 will be done on maint and merged upwards into master, new 
development goes on master only.

Keeping a branch head for old maintenance branches is important for another reason. Suppose 
the maint-2.6 branch name is not pushed into the main repository we would get a commit log 
like this:

A - B - C - E -    (master, maint)
  \   /
    D

But as branches are equal in git this could just as well be written as

A - D - C - E -    (master, maint)
  \   /
    B

(I swapped D and B in case you're wondering). And suddenly it looks as if commit D has always 
been part of master and commit B may have been the bugfix. So without the branch name it's 
impossible to determine what was what in history.

Geert