Merge Conflicts Like A Boss

Introduction

First of all, I just wanted to start by saying how much I love Git, looking at GitHub alone, it’s great, you have everything bundled into one. A platform to implement source control, in addition to being able to report issues, use kanban boards, etc.

If you’re not familiar with Git, not to worry, you can think of a merge conflict as a scenario where two people have conducted some degree of work on some file or some set of files. But you want to merge the changes that you’ve both made into one, how would you go about doing that? This is where Git is clever & will state that a given file or a given set of files become marked as merge conflicts.

This just means that you need to manually confirm what changes you’d like to keep, it’s honestly that simple.

A Little Story

The only issue I’ve ever had with Git has typically been when dealing with merge conflicts. As an example, a member of my team at Admiral Group, she was doing some work on one of our projects not so long ago, she created a branch while carrying out her work, all was well. Only, when she wanted to merge her work into master, we had merge conflicts, that wasn’t a big deal, I told her to merge into master on her local repository, then use the command git mergetool. We resolved the conflicts, only we forgot to use a command such as git clean -fd, so a bunch of files named <file nae>.orig.<file extension> were pushed to this branch. However, for some reason, in the UI or on the GitHub platform, it said that there were still conflicts, so we were unable to resolve her PR.

When using Git locally, there were no conflicts, this put us all in a pickle, I tried a variation of techniques, little worked, until finally I tried a technique that included the following steps:

1. Checkout a commit, on her branch, before any of the changes she had made.
2. Commit those changes, as it was stating that the changes she had made at that point were new changes, even though technically they weren’t.
3. Merge that commit with her most recent commit.
4. Then commit this as a change.
5. Now try to merge into master, resolve the conflicts using vimdiff, or whatever tool you want.
6. Finally push this as a change.

Suddenly, the UI was okay with allowing us to resolve the PR that my colleague had raised, all was well.

The Outcome

You may be thinking something along the lines of:

Cool story bro, you should write a book about it.

Opinions of my little tale

Which is reasonable, but I told you this story to illustrate how much developers tend to struggle with merge conflicts, some even appear anxious when dealing with merge conflicts. I’m here to tell you there’s no need, it’s easy, Git is such an awesome tool, all we need to know is how to utilise it effectively and efficiently.

This is why I personally prefer to use the CLI or Git bash over some GUI, I know a lot of the commands off the top of my head, such as the diff & status commands, they’ve helped me out more than I care to imagine. Talking about these commands, this is also how I illustrated to my group that with the changes I’ve done, there’s no need to panic, I didn’t do anything weird such as introducing breaking changes. I simply resolved the merge conflicts on behalf of my colleague, since it was the end of the day & we all wanted to go home. To do this I showed them the command I used to highlight the differences between my most recent commit & my colleagues most recent commit, i.e. git diff <my new commit hash> <other commit hash>.

There are many different tools that can help us resolve these merge conflicts, vimdiff is just one & it’s the one that I will typically use for the most part. But there’s all sorts, like tortoisemerge, originally made to resolve conflicts in SVN, yet it still works with Git, there’s Meld, hell, most IDE’s these days have some form of tool to handle these merge conflicts. So there’s really no need to worry, just take your time, go at a rate that make you comfortable, where you feel confident in what you’re doing is correct, even if you have a deadline, worst case scenario, just work a little past your companies operation time(s), it’s not a big deal. Of course, there maybe niche scenarios where you’re unable to continue working past operation hours, but if you’re able to, why not? Just take the path of least resistance provide it doesn’t introduce unnecessary risk, ensuring that you’re not jeopardising your work.