I studied Shotokan Karate for 20 years. At the start of each class, you’d say the Dojo Kun. At the beginning, I viewed the sayings as the rules of engagement, similar to FIFA laws. But over the years and decades, it starts to bleed into your subconscious as a way of viewing other situations in life. The most important of these rules is the last, “Refrain from violent behavior.”  The idea is you’re supposed to avoid any fights, etc. at all costs. Because of this philosophy, I have argued that karate is really the study of non-violence. I could go on and on about the importance of the only winning fight is the one that isn’t started, there’s no such thing as a first punch in karate, and so forth.

The first time I saw <<< HEAD and >>>> branch-name edited into my code*, my coffee mug went flying across the room.

Today’s tip is a walkthrough of resolving a merge conflict from within Visual Studio. We’ll cover command line in upcoming tips. Must… pace… self…

Suppose you have some existing output text in our ConsoleApplication in master. And you’re going to merge in text from a branch called decorations that also includes output text. Because both branches have changes in the same section, you’ll get a merge conflict. Let’s see how Visual Studio 2017 handles it.

First, do everything as shown in previous tips…

But this time when you hit Merge, you’ll see the following

Take a deep breath.

Now take another deep breath.

Resist the temptation to “fix” your code by removing the <<< HEAD and >>> decorations modifications. Let your build errors light up like rush hour traffic in your VS code margin gutter thingy.

Now click Conflicts: 1

You’ll be given an option to either Merge or simply take either the code from decorations or master w/o “merging”

Clicking the Merge button will take make use of that <<<< HEAD and >>> decorations gobbledygook by presenting you with a merge tool (in this case presented within VS).

Suppose you want both changes. You can click the checkboxes on both sides and you’ll see the result in the bottom screen.

Notice how the resulting merge shows the Console.WriteLine() at the wrong location, which makes sense. The two code blocks were merged in a way that makes sense.

The bottom window is editable. A quick cut and paste puts the WriteLine() before the ReadLine() so it can be seen before the keypress to exit.

Hit Save and then hit Accept Merge at the top of the merge tool

And yet another button!! O_O

Now back in Team Explorer, click Commit Merge.

Finally, we’re going to finish the merge by typing in a custom commit message and clicking Commit Staged

And now when you view history, you’ll see the merge into master.

*What I’ve realized from learning RoR and Node.js last year is that when you’re not using a full end-to-end IDE (e.g. text editors like atom, vi, sublime, etc.) you need another way to communicate changes and other sort of “metadata.” Hence the content of the code is modified, e.g. adding the <<<< HEAD directly into the file or adding a readme.md file to your repo (which doesn’t participate in the build). Once you start to know the backstory why things are the way they are, the world becomes a lot safer for coffee mugs.