Re: [boost] [git] neglected aspects

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

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.

-Julian