Branching strategy for git

Geert Janssens janssens-geert at
Thu Mar 27 04:47:30 EDT 2014

On Tuesday 25 March 2014 09:17:29 John Ralls wrote:
> On Mar 25, 2014, at 8:15 AM, Geert Janssens <janssens-geert at> wrote:
> > If no one beats me to it I'll try to adapt the git wiki page with
> > this info in the coming days.
> OK. The main change seems to me to be that instead of making a '2.6'
> branch next week I'll be making a 'maint' branch.
> Have you experimented at all with what the upstream looks like if you
> merge a private branch instead of rebasing it and then push the
> result? I *think* the private branch's objects will get pushed
> upstream, but the ref/heads entry won't, but I don't know that for
> sure. If I'm right, then the other change in the wiki will be to
> remove all of the stuff about rebasing instead of merging.
Do you mean there should be no reference to rebasing anymore and to promote merging for 
everthing ?

I think it still makes sense to rebase local branches right before making them public (which can 
be either by pushing to a public repository for those that have commit access or by creating a 
pull request).

This somewhat limits the number of multi-parent commits in the public repository. Lots of 
those tend to make history harder to read or represent.

> 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.


More information about the gnucash-devel mailing list