Do you feel comfortable merging code?

Question

This morning, I read two opinions on refactoring.

• Opinion 1 (Page not present)
• Opinion 2 (Page not present)

They recommend branching (and subsequently merging) code to:

1. Keep the trunk clean.
2. Allow a developer to walk away from risky changes.

In my experience (particularly with Borland's StarTeam), merging is a non-trival operation. And for that reason, I branch only when I must (i.e. when I want to freeze a release candidate).

In theory, branching makes sense, but the mechanics of merging make it a very risky operation.

My questions:

• Do you feel comfortable merging code?
• Do you branch code for reasons other than freezing a release candidate?

Answer 1

Branching might be painful but it shouldn't be.

That's what git-like projects (mercurial, bazar) tells us about CVS and SVN. On git and mercurial, branching is easy. On SVN it's easy but with big projects it can be a bit hardcore to manage (because of time spent on the branching/merging process that can be very long -- compared to some others like git and mercurial -- and difficult if there are non-obvious conflicts). That don't help users that are not used to branch often to have confidence in branching. Lot of users unaware of the powerful uses of branching just keep it away to not add new problems to their projects, letting the fear of the unknown make them far from efficiency.

Branching should be an easy and powerful tool we'd have to use for any reason good enough to branch.

Some good reasons to branchs:

• working on a specific feature in parallel with other people (or while working on other features alternatively if you're alone on the project);
• having several brand versions of the application;
• having parallel versions of the same application -- like concurrent techniques developped in the same time by to part of the team to see what works the better;
• having resources of the application being changed on a artist/designers (for example in games) specific branch where the application is "stable" while other branches and trunk are used for features addition and debugging;
• [add here useful usages]

Answer 2

Some loose guiding principles:

• Branch late and only when you need to
• Merge early and often
• Get the right person to do the merge, either the person who made the changes or the person who wrote the original version are best

Branching is just another tool, you need to learn how to use it effectively if you want the maximum benefit.

Your attitude to branching should probably differ between distributed open source projects (such as those on Git) and your company's development projects (possibly running on SVN). For distributed projects you'll want to encourage branching to maximize innovation and experimentation, for the latter variety you'll want tighter control and to dictate checkin policies for each code line that dictate when branching should / should not occur, mostly to "protect" the code.

Here is a guide to branching:
http://www.vance.com/steve/perforce/Branching_Strategies.html

Here is a shorter guide with some high level best practices:
https://www.perforce.com/pdf/scm-best-practices.pdf