I don’t think I’m alone in saying this; early in my career, merge conflicts were the bane of my existence (particularly in 2019). I graduated from a coding boot camp in 2018, and during that time, if I ever experienced a git issue that I didn’t know how to fix, I would create a new repository and start over. In 2019, I started working as a software engineer with a team of other software engineers, so I couldn’t create new repositories to avoid this inconvenience. I had to face my fears and fix merge conflicts. No exaggeration; the experience would bring me to tears. See the screenshot below of me making a self-deprecating joke about mishandling merge conflicts on July 14, 2019.

Fortunately, today, I’m more comfortable with resolving merge conflicts. It still stresses me out a bit, but I have a few tips and tricks I use to resolve the situation.

Prerequisites to resolving a merge conflict

Breathe

It’s okay. Conflicts happen. You’re not the first person to experience a merge conflict. Everyone experiences merge conflicts frequently regardless of their seniority. It’s a common occurrence in version control.

Understand why merge conflicts happen

Version control systems, like Git, auto-magically manage code contributions. It identifies the change, when it was made, who made it, and on what line so that developers can easily track the history of their codebase. However, Git sometimes gets confused in the following situations:

• When more than one person changes the same line in a file and tries to merge the change to the same branch
• When a developer deletes a file, but another developer edits it, and they both try to merge their changes to the same branch.
• When a developer deletes a line, but another developer edits it, and they both try to merge their changes to the same branch
• When a developer is cherry-picking a commit, which is the act of picking a commit from a branch and applying it to another
• When a developer is rebasing a branch, which is the process of moving a sequence of commits to a base commit

Git is unsure which change to apply, so it leans on the developer for help and notifies them of a merge conflict. Your job is to help Git determine which proposed change is most accurate and up to date.

Resolving Merge Conflicts

In Visual Studio Code (or IDE of your preference)

Read the logs

When you run git merge and a merge conflict occurs, your terminal or command prompt will respond with a message like:

CONFLICT (content): Merge conflict in [filename]

This message means a conflict occurred in this particular file.

Find the conflict

Navigate to the file that Git indicated had a merge conflict and scroll through the file until you find the conflict. Your IDE may indicate where the merge conflict occurred by highlighting the changes the conflicting changes made to the file. The below example shows how VS code may highlight the conflicting changes. VS Code highlights the current change and the incoming change.

The current change (sometimes called an outgoing change) represents the code changes that you made on your local branch.

The incoming change represents the code changes you are pulling in from the base branch or modifications made by other developers.

Decide which changes need to be applied

Deciding if you want to accept current changes, incoming changes, or all the changes depends on the ultimate goal for your program. This part is up to you, your knowledge of what changes are needed, and your team.

If you’re unsure which changes to accept, it’s best to consult with your team or developer who wrote the incoming changes. You can accept changes without committing the code and test program locally for a sanity check.

Remove any lingering ==== , <<<<, or >>>> symbols

Those symbols are used to help you determine where the merge conflicts occurred. When you accept the preferred changes, those symbols usually disappear, but sometimes a glitch happens, and they don’t disappear. You don’t want accidentally commit those symbols if they persist in the file because that can create bugs in your program.

What if I make a mistake?

If you make a mistake or you’re not confident which the decision change to accept, you can stop the merge process by running the following command:

`git merge -- abort`

After you do that, don’t sit there and get frustrated. Reach out to a teammate (preferably one whose code is conflicting with yours or an engineer you can trust) and explain the situation saying: “Hey, I’m experiencing a merge conflict when I try to merge my code. I’m not feeling confident about which changes I should accept. Do you have any availability to pair with me for a few minutes?”

If you’re feeling confident about the resolved merge conflict, commit the changes

After you accept the necessary changes and you’re ready to commit the change, you can take the following steps:

• Save the files where changes were made
• Run git status to ensure the right files were changed
• Run git add [file name] to add the files you changed to staging
• Run git commit -m “[add your commit message here]” to commit your changes
• And then run git push

On GitHub.com

Identify which files have a merge conflict

When you open a PR on GitHub, it will let you know that there are merge conflicts and which files have conflicts.

Find the conflicts

To find the conflicts, click ‘Resolve conflicts’, and it will lead you to the files with conflicts.

Decide which changes need to be applied

The GitHub Web UI will highlight the conflicting changes with yellow and the following symbols: <<<<< ====, >>>>.

It will also indicate which branch those changes are coming from. This should help you determine which changes you want to accept.

Deciding if you want to use the changes from your branch, the base branch, or both depends on the ultimate goal for your program. This part is up to you, your knowledge of what changes are needed, and your team. Delete the lines you don’t want and keep the ones you do want.

Remove any lingering ==== , <<<<, or >>>> symbols

Those symbols are used to help you determine where the merge conflicts occurred.You don’t want accidentally commit those symbols because that can create bugs in your program.

If you’re feeling confident about the resolved merge conflict, commit the changes.

Once you remove the conflicting changes and any symbols used to highlight the conflicting changes, click ‘Mark as Resolved’ and click the ‘Commit merge’ button to commit your changes.

You can read more about merge conflicts and how to resolve them on GitHub’s official documentation.

Comment below if you have follow-up questions! Share this post if you find it helpful.