Merge Headache — Don’t Re-Purposes a class, create a new one

Merging code does not have to be the frustrating process that many people experience, if done right. I have learned during my career that if I pull from my master branch daily, if not more often, my merges are almost always pain free. Now I am not saying that merging is always pain free. There will be times where significant or simultaneous changes to a file introduce pain. There will also be times when a codebase is undergoing structural changes that you will experience issues, but honestly if the changes to the code are standard I attest that merging code should not be too painful.

However, there are things developers can do which directly introduce pain and frustration into the merge process. One of these things is re-purposing a file with almost an entirely new code base. When I say re-purposing, I mean NOT changing the name, but changing 80% of the logic inside the file.

Imagine you have a file called Baz.cs and inside of this file you have a class named Baz. Now image you made changes to the Baz class, inside the Baz.cs file. Now, at the very same time you are making changes to Baz.cs someone else (in another branch mind you) is also making changes to Baz.cs. However, their changes not only change the contents of the Baz class, they rename the Baz class to Bar. While renaming Baz to Bar they also introduce signficnat changes to the body of the class.

The issue here is that when you attempt to do a merge or rebase your SCM system is going to flag almost every line with a conflict, but not all lines (depending on the changes of course). This will leave the person doing the merge to have to make a decision on what to do. Do you take the changes as is, are your changes still needed, do you need to create a new class/file so that you can have both set of changes? What should you do? How do you complete the merge without blowing the prior changes out of the water?

To avoid this type of merge headache what should you do? In my opinion, if you are going to change the intent of a class or the intent of a file you should create a NEW file and delete the old one. If this process had been followed in this scenario the Baz.cs file would have been deleted and the Bar.cs file would have taken its place. This would have allowed me to not deal w/ the merge issues if I knew the file was no longer needed or possibly undo the delete if I know my original changes are still needed.

Keeping the merge process pain free is not too hard, but it does require a bit of fore thought and planning.

Till next time,

This entry was posted in Git, Uncategorized and tagged . Bookmark the permalink. Follow any comments here with the RSS feed for this post.