I really enjoyed the article and recommend it to anyone considering using a distributed version control system (like Git), or even the non-distributed ones that promote branching, ClearCase and RTC’s scm come to mind.
As a consultant, I have run into the branching nightmare scenario time and time again. In fact, I spend a lot of effort moving clients to mainline development. So, though feature branching and distributed version control system’s prolific support for it may seem new it has been around for a long time. In the past though it was typically born from necessity, not forward thinking choice. Usually I hear something like, “We had to create [feature] branches because the developers kept breaking everything.” Can you guess the result? The developers still broke everything, but all the problems were saved until the end of the project. After a hard code freeze there would be 6 weeks of branch merging, aka: Integration Hell.
I thought we (as an industry) figured out a better way back in `99 with the Extreme Programming white book – Continuous Integration! If it hurts, do it more often, not less. Don’t save up all the pain for one big blast. Spread it out, in tiny bits, over the course of the project.
So, why are feature branches still a consideration? Because continuously integrated code bases require some architectural craftiness. In truth, it can be challenging. Architecting big enterprise systems provides enough challenges on its own. “Now you CI guys want us to make the application modular?” (Actual quote)
Yep, that’s right. At the recent “How to be really awesome at CI” panel at Agile 2009, Tom Sulston chaired a panel including myself and several other folks with deep CI experience. A question was asked about how to achieve the “check-in every hour” mantra I was pushing, without breaking everything in the codebase. Yes, feature branches were mentioned. Feature hiding was mentioned. Modularization (componentization) was mentioned. There are lots of great ways to achieve this that don’t require you to put your team back into Integration Hell territory.
Fowler, in the aforementioned article, lands on:
I much prefer designing the software in such a way that makes it easy to enable or disable features through configuration changes. My colleague Paul Hammant calls this Branch by Abstraction. This requires you to put some thought into what needs to be modularized and how to control that variation, but we’ve the result to be far less messy [than] relying on the VCS.