Branching strategy for git
Geert Janssens
janssens-geert at telenet.be
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 telenet.be> 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.
Geert
More information about the gnucash-devel
mailing list