You are so proud to be a developer. You spend so much time working on a feature. You write beautiful unit tests for each and every one of the possible conditions of the requirement (before writing a single line of non-test code, right? Long live TDD)... and you see so many of those tests fail.... can hardly wait to write the code that will actually take care of them! Then you sit down to write the actual code for the requirement... and all tests are back to green! You push and create a beautiful PR... a sequence of self-explaining changes... the closest thing code can make it to poetry. The PR gets merged into the main branch and it’s all beautiful. Kudos from everyone. You go back to coding another thing... after sipping a nice cup of freshly brewed coffee, of course.
3 weeks go by. You are pulled into a phone meeting... do I need to specify that it was without notice? I mean, in what other fashion would you be pulled into a meeting with all the top brass of the development team and production support? After a few minutes of trying to get some context, you finally get to realize that the conversation of all those stressed-out voices spread in 6 different time-zones in 3 continents is spinning around the beautiful piece of poetry that you had written before... it is actually broken... IN PRODUCTION. A FIX IS NEEDED .... NOW!!!
So... after getting your heartbeat kind of half-way back to normal, you sit down to see the code of what is in production.... and, wait a second.... your PR is not complete!!!! One piece of it was left out... actually, a lot of it was left out. But how??? After some digging, you realize that there was a merge when the production branch was going to be cut and the code of your PR was... well, botched while solving conflicts. So you are on the line and it’s not even your fault. Oh, and before I forget... remember those beautiful tests that would put Jorge Luis Borges to shame that you spent so much time writing? Well, half of them were removed because they were failing after the botched conflict resolution and who wants to see failing tests when going in production?
Dealing with conflicts is a tricky subject. Developers spend so much time writing code. Actually adding, modifying and deleting code.... moving it around, reformatting it, refactoring, improving 1... etc. As we have moved to Distributed Version Control Systems (or DVCS, for short), git specifically, we are running way more often operations that make conflicts show up so, in fact, most of us developers spend some time dealing with conflicts, even if painfully, every once in a while.
What normally happens is that a project is developed by multiple developers independently and then all this separate work has to be put together. When git tries to merge the work that was developed in two separate directions it tries its best to figure out how to put it together programmatically.... however, there are some situations where git will give up and raise its hands asking for a person to actually take a look at the code to help git sort it out. When this happens, it is called a conflict.
There’s nothing wrong with having conflicts. In the old days when Centralized VCSs were the norm you had these long running branches that were merged every now and then because of how time-consuming the task can be. However with the advent of Distributed VCSs merging is much more frequent and you have many more opportunities to generate conflicts with operations that were not used often (if not completely missing from centralized VCSs) like cherry-picking, rebasing or stashing.
After a while of dealing with conflicts, developers try their best to avoid them because of how long and how complex it can be to take care of them, specially true if the code involved is not familiar to the person trying to merge the code, but once it is in front of you there’s not much you can do to avoid it. You can either find a way to merge together the conflicting pieces of code... or you rewrite the whole section of code from scratch (and let’s hope you have a great set of tests to make sure you are not breaking anything)... or you can give up and cancel the merge operation and wait for a day with a bluer clearer sky to try again.
Given the amount of time if takes to master the skills to be a proficient merger and seeing how little structured material there is out there to explain how to deal with conflicts, I have decided to do the proper and write a basic guide to help people deal with them.
I hope that by the time you finish reading this guide you find yourself more comfortable when facing them.
Copyright 2020 Edmundo Carmona Antoranz