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