Solving Git merge conflicts with three-way merge view
Merging two versions of the same file results in a conflict when the version control system cannot decide how to reconcile the two versions. If Git cannot automatically perform a merge, it annotates the conflicting lines with special markers. By default, Git produces a two-way merge view of the files, directly comparing these two distinct versions:
<<<<<<< HEAD
Banana
=======
Apple
>>>>>>> fruit-feature
Orange
Mango
In the situation above, we can see that the HEAD
contains the line “Banana” on the first line, while the branch fruit-feature
contains “Apple” instead.
We can solve the conflict manually, without using any special merge tools, by removing the markers and keeping the code we want in any text editor.
The problem with merging, though, is almost never about the mechanics of the editing but rather about figuring out what the result should look like. Should we keep the banana, apple, both, or none?
One of the best ways to help us get the context of the merge is to use three-way merge view, because it will produce a base revision (nearest common parent) along the two versions:
<<<<<<< HEAD
Banana
||||||| c0e4389
Apple
Banana
=======
Apple
>>>>>>> fruit-feature
Orange
Mango
As we can see, the original parent c0e4389
has both “Apple” and “Banana”, effectively showing that the branches were both deleting items and the conflict should be resolved by deleting both entries.
You can tell Git to use three-way merge by setting merge.conflictstyle
to diff3
in the Git configuration:
# in .gitconfig
[merge]
conflictstyle = diff3
Code editors can also color-code the lines when viewing conflicting files. Here is how it looks like in Visual Studio Code:
Using three-way merge view has been the single biggest improvement in my ability to resolve conflicts. If you are not using it yet, take it for a spin.
Petr