By June 2, 2010

Merge Code In… Merge Code Out…

Merging is source control Kung-Fu.

I’ve seen many people get taken to the mat when trying to merge code.  Today, I’m going to give you a simple technique that can help save you the embarrassment of your favorite source control program kicking you right in the head.

Bring the plate to the food

Often as a kid the table would be set and dinner would be ready.  I would try and take some food from the kitchen over to my plate on the table.  (Grab the hamburger and carry it over to the plate.)

My dad would often tell me,  “Bring the plate to the food.”

Which would mean that I would have to take the plate from the table.  Bring it to the kitchen.  Put the food on the plate.  Bring the plate back to the table.  Oh, what a hassle.

Less food ended up on the floor that way.  Now it seems obvious to me.  But, back then it didn’t.

So it is with merging

It is exactly the same way with merging.

Wise-man once say:

If you want to merge code to a location, you must first merge code from the location

Anytime you are about to merge code to some branch, always merge code from that branch first.

Let’s say that you created a branch off of your trunk.  You started working in that branch and you are done with whatever you are doing there.  You are ready to merge code back up to trunk.

  • First merge trunk to your branch
  • Resolve any conflicts
  • Test on your branch
  • Then merge your branch (that has the trunk changes already) into trunk

Why can’t I just merge to the destination, why merge in first?

It may seem like a bunch of overhead, but if you’ve ever merged to trunk or a release branch and broke it for everyone, then scrambled to try and fix it, you’ll probably see the benefit in making sure that all merges to release branches or trunk are trivial.

A trivial merge is a merge that can be automatically done by your source control.  It doesn’t require human interaction.

If you merge in, and then merge out, the merge out will always be a trivial code merge.  So in reality you're not really adding any overhead at all.  You are just handling the possibly difficult code merge on your branch as opposed to the trunk or release branch.

Another important reason is that you want to be able to test your changes with the other changes that have happened in the system since you branched off.  Most of the time other changes will be happening at the same time you are making changes.

The only way to know what the interactions will be is to test them.  The best place to test them is on your local branch so that you don’t interfere with everyone else.

Derick Bailey provides an excellent detailed description of what I am talking about in his post on merging.  He calls it the merge dance.

My dev cave

Without further adieu, here are the pictures of my dev cave I set up for my new job.



About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."