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 s

Answer 1

I've only done it a couple times, so I'm not exactly comfortable with it.

I've done it to conduct design experiments that would span over some checkins, so branching is an easy way to wall off yourself a garden to play in. Also, it allowed me to tinker while other people worked on the main branch, so we didn't lose much time.

I've also done it when making wide ranging changes that would render the trunk uncompilable. It became clear in my project that I'd have to remove compile-time type safety for a large portion of the codebase (go from generics to system.object). I knew this would take a while and would require changes all over the codebase which would interfere with other people's work. It would also break the build until I was complete. So I branched and stripped out the generics, working until that branch compiled. I then merged it back into the trunk.

This turned out pretty well. Prevented a lot of toe-stepping, which was great. Hopefully nothing like this will ever come up again. Its kind of a rare thing that a design will change requiring this kind of wide ranging edits that don't result in a lot of code being thrown out...

Answer 2

Do you feel comfortable branching code?

It really depends of the tool I'm using. With Starteam, branching is indeed non trivial (TBH, Starteam sucks at branching). With Git, branching is a regular activity and is very easy.

Do you branch code for reasons other than freezing a release candidate?

Well, this really depends of your version control pattern but the short answer is yes. Actually, I suggest to read the following articles:

• Version Control for Multiple Agile Teams by Henrik Kniberg
• FeatureBranch by Martin Fowler

I really like the pattern described in the first article and it can be applied with any (non Distributed) Version Control System, including Starteam.

I might consider the second approach (actually, a mix of the both strategies) with (and only with) a Distributed Version Control Systems (DVCS) like Git, Mercurial...

Answer 3

Branching is trivial. Merging is not. For that reason, we rarely branch anything.

Answer 4

Using SVN, I've found branching to be relatively painless. Especially if you periodically merge the trunk into your branch to keep it from getting too far out of sync.

Answer 5

I use svn, it takes less than a minute to branch code. I used to use Clearcase, it took less than a minute to branch code. I've also used other, lesser, SCMs and they either didn't support branches or were too painful to use. Starteam sounds like the latter.

So, if you cannot migrate to a more useful one (actually, I've only heard bad things about Starteam) then you might have to try a different approach: manual branching. This involves checking out your code, copying it to a different directory and then adding it as a new directory. When you need to merge, you'd check out both directories and use WinMerge to perform the merge, checking in the results to the original directory. Awkward and potentially difficult if you continue to use the branch, but it works.

the trick with Branching is not to treat it as a completely new product. It is a branch - a relatively short-lived device used to make changes separately and safely to a main product trunk. Anyone who thinks merging is difficult is either refactoring the code files so much (ie they are renaming, copying, creating new, deleting old) that the branch becomes a completely different thing, or they are keeping the branch so long that the accumulated changes bear little resemblance to the original. You can keep a branch for a long time, you just have to merge your changes back regularly. Do this and branching/merging becomes very easy.

Answer 6

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