Branching strategy for git

[Geert Janssens]

On Saturday 22 March 2014 18:39:13 John Ralls wrote:
> On Mar 22, 2014, at 4:01 PM, Geert Janssens <janssens-geert at telenet.be> wrote:
> > > Is 'stable' going to be per-release-series, i.e., will we have
> > > 'stable-2.6' and in two years 'stable-2.8'? Or do we have a single
> > > 'stable' that gets 'master' merged into it at the time of an x.x.0
> > > release?
> > 
> > I like the workflow as proposed in the git workflows man page
> > (section Branch management for a release and following). They
> > propose a long-term maintenance branch. Only when a new feature
> > release is done, a separate maintenance branch for the previous
> > stable series is created. So when 2.8.0 gets tagged, the current
> > head of stable is branched off into stable-2.6. Then stable is fast
> > forwarded to the 2.8.0 release tag.
> It won’t quite fast-forward because of ChangeLog and NEWS, but those
> are minor issues; the releaser can just resolve to the new version.
> > 
It certainly looks like Changelog and NEWS are features from another era that don't map very 
well to modern version control systems...

I suppose resolving to the new version is easiest.

> > Do we want an integration branch (called 'next' by both examples) ?
> > It can help predict merge conflicts and experiment with conflict
> > resolution before merging from stable to master. Or is our team too
> > small for that ? It can be added in a later phase as well of
> > course. It would be an upgrade of the basic workflow, not a
> > different workflow.
> ‘Next’ and ‘maint’ are just different names for ‘stable’ and ‘release’
> in your original proposal.
> 
The way I understand it 'next' is neither 'stable' nor 'release'. It's a testing branch, a testbed 
to merge various different branches before they are merged into 'master' or 'maint'. It's a 
disposable branch which gets reset at each major release. But that's not so important for us - 
see below.

> As long as we’re not listening to the Github siren (the Odyssey kind,
> not the one on police cars) and merging directly into the public
> repo, there’s every opportunity to test-merge and reset back as
> necessary in one’s private repo and no need for a public branch on
> which to commit before merging.

I had to read this a few times to get the sense of what you meant. I presume you were saying 
we shouldn't be using Github's web interface to deal with pull requests into the repositories at 
github.com/Gnucash. If that's what you meant, yes, I agree.

I believe the intention of a public branch like next or 'pu' in the git workflow is to ensure that 
several features worked on in topic branches still integrate nicely. In a large project such an 
'integration' branch is public because there are many developers involved and doing the 
integrations locally will limit what gets tested.

As I suggested before the GnuCash development team seems too small to benefit from such a 
branch. And if needed we can always add one later on.

So to start I agree we don't need an integration branch.

> > And what names do we want to use for our public branches ? Should we
> > just stick to the git workflow examples (maint, master, next) ?
> > That would make it easier to refer to the man page as the reference
> > for our workflow.
> I’m fine with ‘master’ and ‘maint’.
> 
Ok.

So with that I think we have a good first strategy to start with. If we find details later on that 
don't work very well we can always adjust.

If no one beats me to it I'll try to adapt the git wiki page with this info in the coming days.

Geert