Dealing with Merge Conflicts

Today, we’ll talk about some kind of a scary topic: merge conflicts.

The first thing you should keep in mind is this: you can always undo a merge. This means you can go back to the state before conflicts occurred. You’re always able to undo and start fresh.

Also, a conflict will only ever handicap yourself - and not your teammates. That’s because in Git, conflicts can only occur locally, on a developer’s machine - and not on the server.

Let’s start by looking at how a conflict occurs - and what it actually is.

In Git, there are a couple of operations that integrate changes - for example when merging, rebasing, or cherry-picking. A great thing about Git is that it makes merging extremely easy: in most cases, Git will figure out how to integrate new changes.

However, there’s a handful of situations where you might have to step in and tell Git what to do. Most notably, this is when changing the same file. Even in this case, Git will most likely figure it out on its own. But if two people changed the same lines in that same file, or if one person decided to delete it while the other person decided to modify it, Git simply cannot know what is correct. Git will mark the file as having a conflict - and you’ll have to solve it before you can continue.

Let’s look at this in real life.

Let’s say we want to integrate new changes - from our “development” branch into our current HEAD branch. We start the merge operation by dragging development and dropping it onto the HEAD.

And “boom” here it is: Tower tells us that a conflict occured.

Let’s take a closer look at the conflict file. Git couldn’t merge the changes because, in this case, both versions of the file were modified in the same place.

If we open this file in an editor, we’ll see what such a conflict state looks like. Git marked the problematic area in the file by enclosing it in “angle brackets”. Additionally it tells us which branch those changes came from. HEAD, of course, and the other branch we tried to merge in. The line with those “equal signs” separates the two conflicting changes.

Our job is now to clean up these lines: when we’re done, the file should look exactly as we want it to look. Correct code and no more bracket markers. Maybe your code is correct, maybe it’s a teammate’s code - or maybe a mixture between the two.

The most basic way to do this is indeed with your text editor: change the file to look like it should look. Then save it. And in Tower, choose to resolve using this edited version.

Tower then simply stages the file. This tells Git that the conflict is solved. Finally, you need to commit your resolution like any other change. And this completes the conflict situation.

Let’s replay the conflict once more. Because Tower’s conflict view offers some more options.

In some cases, one or the other version of the file might be correct. In that case, you won’t need to modify the file by hand. You can simply tell Tower that one of the versions is the one you want to use. Simply select it and click the Resolve button.

In other situations, of course, you’ll indeed have to combine both versions into your final, correct one. In those cases, it’s great to have a dedicated merge tool installed and configured.

You can then open your tool of choice right from within Tower.

A merge tool provides a better view on the situation: the two conflicting changes are on the left and right. And you can determine how the final resolution should look like - in a visual way. Choose left or right - or edit the final version yourself.

Saving and then quitting the tool will tell Tower that this conflict is resolved.

Finally, here’s how to undo a merge - in case you want to start over with resolving your conflicts.

Simply click the “Abort” button here on the top. Tower will restore your project as it was before the conflicts occured. Always keep this option in mind. This should give you the confidence that you can’t break anything.

Thanks for watching! And see you in our next video!