Feature Branching vs. Continuous Integration

I posted my thoughts to the topic of Feature Branching vs. Continuous Integration some month ago.

Now here is a very good video interview where Mike Mason and Martin Fowler characterize Feature Branching and the problems that may result from it and where they see that Feature Branching is applicable and where it is not recommended.

And here is an experience report by Sarah Taraporewalla that describes sarcastically the problems you get into with Feature Branching.

The conclusion I take away from that:
Feature Branching is good for loosely coupled collaboration typically found in open source projects. Feature Branching is not recommended for dedicated teams with tight collaboration, which is the type of collaboration you are striving for in a typical Scrum project.

Update 2011-08-14:

Interesting points from the above interview are:

• The pain from merging increases exponentially with the age of your branch.
• In practice feature branches discourages refactoring: You are not improving the core codebase when working on a new feature, because you are afraid of merging those core refactorings back later. You rather build your feature around the existing core, as it is, living with its shortcomings...
• Alternatives are feature toggles and branch by abstraction (archtiectural branching)
• Using feature branches for organizational control is a sign of a dysfuntional environment. If you don't trust your team to commit frequently, then you have a problem that can't be solved with a version control system.

Related is the article by Martin Fowler describing Semantic Conflicts. The main conclusion there is that tools only can support in merging textual conflicts but they can never solve semantic conflicts.

If you like this, follow me on twitter...