Merging and Branching
Joe Morrison talks about branching and merging in his latest post. I was about to comment on his blog, but my response became so long that it probably deserves a post on its own, so here goes.
Many established (old school/expensive? 🙂 ) SCM systems (Clearcase, Continuus/Synergy etc) are built around making carefree branching easy, and indeed desirable. However, they also are heavily centralised systems, and thus I feel a slight sense of irony around the current hype on distributed version control, which are really all about having your own private branch(es).
The primary use-case for git in the Linux kernel development is the patch workflow: the ability to create, maintain, verify and apply individual patches. The lack of a centralised server is really an optional extra, a nice side effect.
Which brings me to my central point — I think what branching strategy to use should really be a function of your release planning methodology. Ask yourself this: Are your releases on a timed schedule, or on a feature schedule? Do you have multiple teams working on features with differing time to market, or is everybody working on a the same schedule? Are your feature sets held constant during development, or are they constantly shuffled? How often do you find yourself slipping planned features from one release to another? These and other such questions should determine your branching strategy.
A good way to think about these issues is shown in a great presentation by Laura Wingerd (that I found linked via Joe’s post), which talks about the concepts of ‘Convergent Branching‘ vs ‘Divergent Branching‘
There is one other consideration that matters – integration environments. For a self contained project, there is no cost to have a multitude of integration environments. However, for more integration oriented projects, even if your SCM enables you to create private branches easily, you’ll need to worry about how to test each branch. How far do you trust your unit tests to go before you’ll want to do integration testing against real backends? Do you need an integration environment for every private branch, or can you get by with integration testing after a merge into mainline?
It is unfortunate that a developer population weaned on CVS and SVN (myself included) are trained to consider merging a pain, and thus force themselves to reduce branch usage. Rather, try and get the tool to follow your requirements, and not the the other way around.