Branching and merging is one of those things in software development that tends to drive most developers right around the bend. It’s understandable why so many fear branching and merging – after all, so many things can go wrong once you veer off the baseline and wander into uncharted territory and try to get back. But instead of fearing the beast, here are two tips to help you drag it up out of the basement, smack it around, and show it who’s boss.
Just so we’re all on the same page, branching and merging is defined as the process of duplicating part of a software development project baseline so that some parallel development can take place, say, to fulfill a customer’s change request, then once completed it’s merged back into the baseline.
The fat can hit the fire in two places: first, determining when and why a branch should be started, and then when and how it’s merged back into the main development baseline. Done poorly, both of these actions can result in confusion, errors, and delays. No wonder branching and merging gives developers night-sweats.
Because branching and merging has the potential to be problematic, some developers unintentionally make it worse by either branching too often or merging too late. The result can be increased risk in errors and/or a decrease in productivity.
So what’s a developer to do?
Start by determining what should rightfully constitute a branch – does a branch get triggered by a change request? How about a specific integration effort? Perhaps it’s based on system architecture? These are just a few of the common branching strategies, so you need to decide which one provides you with an acceptable balance of risk versus productivity. Do you want to branch and merge early and often, reducing risk but also slowing productivity? Or are you willing to roll the dice that things go smoothly during development so you’ll hold off on merging to potentially increase productivity and value?
Where things can get really sticky is in the merging process.
So my second tip is to make sure you can fully track all your file changes, especially across code lines, or you run the risk of some seriously broken builds and test failures. At AccuRev we have a branching model that we call streams which provides some great code flexibility to make branching and merging as fast and efficient as possible. Stream branching easily accepts parent code while allowing you to then push code out to other streams. All file versions are stream-based, making merging easier because the entire file change history is available and automatically tracked. Pretty cool.
Here’s the big pay-off – because branching and merging is made a lot easier with streams, development teams can branch more often and more confidently, reducing risk without seriously impacting productivity. Perhaps best of all, it helps you avoid a potentially-disastrous end-of-release merge dump that could result in costly and time-consuming fixes and release delays.
So let’s recap: avoid a branching and merging nightmare by carefully considering the branching model that best suits your needs and your level of risk versus productivity. Make sure that your methodology provides maximum visibility into the process and enables you to fully track your file change history, enabling better decision-making and ensuring more effective merging that’s less prone to errors. The result? Better product,faster, and with less errors. How sweet is that?
