Advertisements
Posted by: jsonmez | June 2, 2010

Merge In… Merge Out…

Merging is source control Kung-Fu.

I’ve seen many people get taken to the mat when trying to merge.  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 to a location, you must first merge from the location

Anytime you are about to merge to some branch, always merge 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 it 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 merge.  So in reality you’re not really adding any overhead at all.  You are just handling the possibly difficult 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.

devcave1

devcave2

As always, you can subscribe to this RSS feed to follow my posts on Making the Complex Simple.  Feel free to check out ElegantCode.com where I post about the topic of writing elegant code about once a week.  Also, you can follow me on twitter here.

Advertisements

Responses

  1. […] Merge In… Merge Out… (John Sonmez) […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: