Boost logo

Boost :

Subject: Re: [boost] [git] neglected aspects
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-02-11 08:46:52

Julien Nitard wrote:

> Thanks for the effort, but what you proposed is a perfectly valid SVN
> workflow to me. There's nothing specific to git, besides the naming
> conventions of the branches, if I had to draw one for SVN the result
> would be the exact same with s/develop/trunk/ and s/master/tags/.

No, there is a fundamental difference between svn and git. Let me

In svn, by "branch" we just mean a branch of the file tree in the
repository. The repository as a whole has a single history which is a
linear sequence of revisions. So of course you can make a feature
branch, but a commit to that feature branch is really also a commit to
all other branches, the trunk and all tags -- and vice versa. If at
second thought you don't like your last three commits to the feature
branch, you can't just revert history because that might also undo,
say, the last twenty commits other people made to trunk. So you always
have to manually select which files or subtrees to revert.

In git on the other hand, /history/ is what branches and merges. A
commit to a feature branch (your working subhistory) leaves all other
branches (parallel asynchronous subhistories) unaffected. Resetting to
a previous commit also leaves all other branches unaffected, so you
don't have to do any manual selection.

This explanation is mostly in terms of reverting changes, but there is
much more at stake here. Both svn and git allow you to make a
separation of concerns in the file tree, but only git allows you to
make a separation of concerns in history. The git history model
corresponds much better to a situation where different developers are
working in parallel on different tasks at different work paces.

The difference goes so deep that even the commits themselves have a
different "feel". In git, the most natural thing to do is to make many
small commits, each of which represents a logical unit of change; and
because other authors are working on separate branches, all of those
small unitary commits will stay together in history. In svn, when
collaborating with many people, you have to choose between two evils:
either you make many small commits which get interspersed with commits
by other authors, or you collect many changes into one big commit,
which makes it a big commitment indeed.

> On the other hand, whether we use git or SVN, I agree that the current
> model is not efficient. I think that trunk and release are redundant,
> it should be just trunk (this is not recommended just by me, see the
> wikipedia entry on continuous integration that I quoted earlier), with
> tags for releases. Since trunk is automatically tested, I see no
> reason to add an additional step before release that seemed to be
> completely neglected by developers.
> Removing that unecessary (IMHO) release branch may force people to pay
> more attention to what they are commiting and lower the load on the
> test system (which seems to be a problem) because there's no more
> release to test. Instead, a temporary release branch may be created
> from trunk and worked on directly when the beta is fixed. (And it
> seems to be that this is exactly what you proposed on your git schema)

Yes, basically the purpose of the gitflow develop branch /is/ to be a
continuous integration branch. It's the branch of history where a
project is permanently held in bleeding-edge condition (note that this
would also facilitate nightly builds, for example). Large-ish changes
tend to temporarily mess up the code, so they're isolated in feature
branches to keep the develop branch tidy (though as I explained above,
that's not the only good thing about feature branches). If "tidy" is
not enough and you need to make a "serious" stable release, you fork a
temporary release branch so the continuous integration on the develop
branch can go on without interruption.


Boost list run by bdawes at, gregod at, cpdaniel at, john at