Branching is the black art of version control, and anyone who has tried it at least once has probably had the nightmare that arises from having to merge code back in.

It’s an art worth learning, however. Sometimes you’re working on a feature, or a refactor, that’s significant enough that you can’t risk partial checkins.

Now, for context, I’m a big believer in frequent checkins. Beyond the advice in the linked article, I tend to check in almost any change. Add a method? Check it in. Add a single unit test? Check it in. Version Control is my brain and my undo. I’d rather revert a version or 10, but be confident, than realize I need to go back about halfway through my current rewrite.

Given I like, and in fact need, to check in often, I feel I probably need to use branching more often, as well. An recent example was work we started for a client. Right after integrating the first elements of the new features, the client changed the current request. Entirely. However we were stuck deep enough in a combination of new elements not yet finished and concurrent refactoring that it became easier to comment out large sections of code than refactor. If we’d just branched the new feature set, and continued maintenance on the trunk version, we would have saved ourselves frustration – and the risk that comes from half-finished features that probably won’t ever make it to the top of the backlog again!

What is your philosophy on branching your code base?

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.