Branching strategy for git

[Geert Janssens]

On Thursday 27 March 2014 07:45:14 John Ralls wrote:
> On Mar 27, 2014, at 1:47 AM, Geert Janssens <janssens-geert at telenet.be> wrote:
> > On Tuesday 25 March 2014 09:17:29 John Ralls wrote:
> > > On the matter of feature branches, I'm tempted to create two
> > > public
> > > ones, 'boost' and 'mvc' to provide a long-running context to those
> > > changes and to encourage others to join the fun.  A third,
> > > 'core-sql', would come after the engine has been cleaned up enough
> > > for it to be practical. What do you think?
> > 
> > How much overlap is there in the 'boost' and 'mvc' work ? I'm just
> > trying to estimate if they can be done on separate branches. But
> > perhaps you already have a vision on that.
> 
> The Boost changes will touch everything because it's going to include
> a lot of API shrinkage, like getting rid of most of the different
> ways we say "time", and changing object calling conventions from
> gnc_footype_bar(foo, baz) to foo->bar(baz).
> 
> MVC is more of a refactoring exercise, pulling everything that doesn't
> immediately draw on the screen or get from the user out of the GUI
> code into a controller layer, the objective being to make switching
> UIs a more-or-less mechanical exercise.
> 
> They'll need to be frequently merged back-and-forth with master to
> keep everything in sync. Do you think that will add too much extra
> work and that we should just do everything in master as we have been?
> 
The branching strategy in git will be an experiment for me as I never worked in an environment 
before that used git and a true git workflow. So my opinion on this is mostly academic.

Having said that would definitely do such big refactorings on one or more separate feature 
branches.

I'm interested in getting more familiar with how git can be leveraged to a maximum in the 
development cycle. If people with lots of git experience suggest that branches are the way to 
do this I assume they have good reason to. (Better would be of course if we fully understood 
these reasons ourselves but I don't feel like learning by trial and error in this case.)

For one should the proposed refactorings turn out to take much more time than anticipated and 
we would want to ship a 2.8 with other smaller features that would be easier if the refactorings 
are on their own branches.

That assumes of course that only atomic change sets from the feature branches can be merged 
into master. Not half finished features.

Geert