There is a moment every developer dreads. You run git merge or open a pull request on GitHub, and instead of the smooth green success message you were hoping for, you see the words: CONFLICT — Automatic merge failed. Fix conflicts and then commit the result.

Your first instinct is probably panic. Mine was. But here is what I wish someone had told me early on: merge conflicts are completely normal. They are not a sign that you did something wrong. They are Git’s way of saying two people changed the same part of the same file, and it needs a human to decide which version to keep.

Once you understand what a merge conflict actually is and follow the steps to fix it, the whole process takes less than five minutes. This guide covers everything — what causes conflicts, how to read the conflict markers, how to fix them both on the command line and directly on GitHub, and how to avoid them in the future.

What Is a Merge Conflict?

A merge conflict happens when two separate branches make changes to the same line in the same file, and Git cannot figure out on its own which change to keep.

Here is a simple real-world scenario:

• Developer A is working on the main branch and changes line 10 of style.css from color: blue to color: red.
• Developer B is working on a feature branch and changes the exact same line 10 of style.css from color: blue to color: green.
• When Developer B tries to merge their feature branch into main, Git sees two different versions of line 10 and does not know which one is correct. That is a merge conflict.

Git can handle many types of changes automatically — adding new lines, deleting lines that were not touched by the other person, renaming files. Conflicts only happen when both branches edit the same specific content.

How to Read Git Conflict Markers

When a conflict occurs, Git opens the affected file and adds special markers to show you exactly where the conflict is and what both versions look like. Understanding these markers is the key to fixing any conflict.

Here is what the conflict markers look like inside a file:

Here is what each marker means:

• <<<<<<< HEAD Everything between this line and the ======= is YOUR current code — the version that exists in the branch you are merging INTO (usually main).
• ======= This is the dividing line between the two conflicting versions. Think of it as the separator.
• >>>>>>> feature-branch Everything between ======= and this line is the INCOMING code — the version from the branch you are trying to merge IN.

Your job is to decide: do you want to keep the top version, the bottom version, or a combination of both? Once you decide, you delete all three marker lines and the version you do not want, leaving only the code you want to keep.

Method 1: Fix Merge Conflicts Using the Command Line

This is the most reliable method and works in every situation. Follow these steps exactly.

Step 1: See Which Files Have Conflicts

After a failed merge, run this command to see which files are conflicted:

$ git status

You will see a list of files under both changed to be committed and Unmerged paths. The unmerged files are the ones with conflicts that need fixing.

Step 2: Open the Conflicted File

Open each conflicted file in your code editor — VS Code, Sublime Text, or any editor you use. Search for the conflict markers (<<<<<<< HEAD) to find each conflict location. A file can have multiple conflicts in different places.

Pro Tip: In VS Code, conflicted files are highlighted in red in the file explorer, and each conflict shows colored Accept Current Change and Accept Incoming Change buttons you can click instead of editing manually.

Step 3: Resolve Each Conflict

For each conflict in the file, you have four options:

• Keep your version (HEAD): Delete everything from ======= to >>>>>>> including those lines.
• Keep the incoming version: Delete everything from <<<<<<< HEAD to ======= including those lines.
• Keep both versions: Delete all three marker lines but keep both blocks of code.
• Write something new: Delete all markers and both versions, then write a completely new version that combines or replaces them.

After resolving, the file should look like normal code with zero conflict markers remaining. Before moving to the next step, double-check that you have removed every single <<<, ===, and >>> line.

Warning: Never leave conflict markers in your code. If you commit a file that still contains <<<<<<< or ======= markers, your code will be broken.

Step 4: Stage the Resolved File

Once you have fixed all conflicts in a file, stage it with git add:

Step 5: Complete the Merge with a Commit

Once all conflicted files are resolved and staged, complete the merge:

$ git commit # Git will open a default merge commit message. # You can accept it or write your own: $ git commit -m “resolved merge conflict in style.css”

The merge is now complete. Push your changes to GitHub:

$ git push origin main

Method 2: Fix Merge Conflicts Directly on GitHub

For simpler conflicts, GitHub’s web interface lets you resolve them without ever touching the command line. This works well for small text conflicts in pull requests.

1. Open the pull request that has a conflict on GitHub.
2. Scroll down to the section that says ‘This branch has conflicts that must be resolved’. Click the Resolve conflicts button.
3. GitHub opens a web editor showing the conflicted file with conflict markers highlighted.
4. Edit the file directly in the browser — remove the conflict markers and keep the code you want.
5. Once all conflicts in the file are resolved, click the Mark as resolved button in the top right corner.
6. If there are multiple conflicted files, repeat steps 4 and 5 for each one.
7. Click Commit merge to complete the resolution.

Pro Tip: The GitHub web editor works best for simple conflicts — one or two lines. For complex conflicts involving many files or large code blocks, use the command line method for better control.

Method 3: Fix Conflicts Using VS Code (Easiest for Beginners)

VS Code has built-in merge conflict resolution that makes the process very visual and beginner-friendly. When you open a conflicted file in VS Code, it automatically highlights the conflict and gives you clickable options.

• Open the conflicted file in VS Code. The conflict will be highlighted in color — blue for your version, green for the incoming version.
• Above the conflict you will see four clickable options: Accept Current Change, Accept Incoming Change, Accept Both Changes, and Compare Changes.
• Click whichever option matches what you want to keep.
• If you need a custom combination, click Compare Changes to see a side-by-side diff, then edit manually.
• Save the file after resolving.
• Open the VS Code terminal and run git add . followed by git commit.

What If You Make a Mistake? How to Abort a Merge

If you start resolving a conflict but realize you have made things worse, or you just want to start over, you can abort the entire merge and go back to the state before you started:

$ git merge –abort

This command cancels the merge completely and restores your branch to exactly where it was before you ran git merge. Nothing is lost. You can take a breath, understand the conflict better, and try again when you are ready.

Warning: git merge –abort only works if the merge is still in progress. Once you have committed the merge, you cannot abort it — you would need to use git revert or git reset instead.

How to Prevent Merge Conflicts in the Future

While you cannot eliminate merge conflicts entirely, good habits reduce them significantly:

• Pull frequently. Before you start working each day, run git pull to get the latest changes from the remote. The more in sync you stay, the fewer conflicts you face.
• Keep branches short-lived. The longer a feature branch exists without merging, the more it diverges from main. Merge or rebase frequently rather than letting branches grow for weeks.
• Communicate with your team. If you know someone else is working on the same file, coordinate who changes what. A quick message saves an hour of conflict resolution.
• Break files into smaller modules. Large files that multiple people edit are conflict magnets. Smaller, single-purpose files are less likely to conflict.
• Use feature flags instead of long branches. Instead of maintaining a separate branch for months, merge incomplete features behind a feature flag so the code merges often but is not active until ready.

Frequently Asked Questions

Can merge conflicts delete my code?

No. Git never deletes anything permanently. Even if you resolve a conflict incorrectly, you can recover the original versions using git log and git checkout to find and restore any previous state of your files.

What does ‘both modified’ mean in git status?

It means both your current branch and the branch you are merging both changed the same file. This is the direct cause of a merge conflict. Git is telling you it needs human help to decide which changes to keep.

What is the difference between a merge conflict and a merge commit?

A merge commit is what Git creates when two branches are joined successfully. A merge conflict happens when that join cannot happen automatically because the same lines were changed in both branches. Resolving the conflict leads to a merge commit.

Does resolving a conflict in GitHub’s web editor affect my local repo?

Yes. When you resolve and commit a conflict on GitHub’s website, those changes are added to the remote repository. You will need to run git pull locally to sync your local copy with the resolved version.

What is git rebase and does it avoid conflicts?

Git rebase is an alternative to merging that replays your commits on top of another branch. It can make history cleaner, but it does not prevent conflicts — it just presents them one commit at a time rather than all at once. Rebase is more advanced and can be risky on shared branches.