Branching strategy for git

Dmitry Pavlov zeldigas at gmail.com
Tue Mar 25 12:52:07 EDT 2014


Branch is just a pointer to head of revisions list (node in revision tree)
.
So if you merge private branch in branch that is then pushed to public, it
will be visible like this:
http://git-scm.com/figures/18333fig0317-tn.png
But without pointer to iss53

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.

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?

Regards,
John Ralls

_______________________________________________
gnucash-devel mailing list
gnucash-devel at gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


More information about the gnucash-devel mailing list