Understanding and Resolving GitHub Merge Conflicts

Understanding and resolving merge conflicts is inevitable when working with Git, especially in a collaborative coding environment. Let’s make it crystal clear for you.

What is a Merge Conflict?

A merge conflict occurs when two branches you’re trying to merge both modified the same part of the same file, and Git can’t determine which version to use. This situation needs manual intervention to decide which changes to keep.

How to Identify a Merge Conflict?

When you encounter a merge conflict, Git uses markers to show you what and where the conflict is.

<<<<<<< HEAD
...
=======
...
>>>>>>> branch-name

The Anatomy of GitHub Merge Conflict Indicators

Suppose you have two branches: master and dev. Let’s understand about conflict indicators.

• <<<<<<< HEAD denotes the start of the conflict area, and HEAD just refers to the branch you’re currently on (master branch, in this case).

• The part between <<<<<<< HEAD and ======= comes from the current branch (HEAD / master branch).

• ======= is a separator between the conflicting changes.

• The part between ======= and >>>>>>> branch-name is the conflicting code from the branch you’re trying to merge (dev branch, in this case).

• >>>>>>> dev denotes the end of conflict area.

An Example

Let’s consider:

In master branch:

print("Hello, world!")

In dev branch:

print("Hello, GitHub!")

On merge, GitHub presents you the conflicting code as:

<<<<<<< HEAD       
print("Hello, world!")
=======              
print("Hello, GitHub!")
>>>>>>> dev         

How to resolve a conflict?

To resolve this conflict, you will need to decide whether to keep the code from your current (HEAD) branch, accept the incoming code from the other branch, or even perhaps a combination of both. It entirely depends on which code is correct or up-to-date with respect to your project requirements.