How to Resolve Git Merge Conflicts, Step by Step

by Souy Soeng /October 25, 2026

Code editor showing Git conflict markers around two versions of a greeting line, Hello and Hi there, in app.js

Git merge conflicts happen when two branches change the same lines of the same file, and Git stops to ask you which version to keep. Nothing is broken. Git simply cannot guess which edit is right, so it hands the decision back to you.

This guide walks through the whole routine in order: run git merge and read what Git tells you, find the conflict markers, edit the file so it says what it should, then stage and commit your fix. It ends with how to check that the merge is truly finished and what to do when something goes wrong.

In short

A merge conflict is a question from Git, not an error: two branches edited the same lines.
Git's merge output names every conflicted file, so read it before doing anything else.
Inside each file, three markers separate your version (HEAD) from the incoming branch.
Keep the right code, delete every marker, then run git add and git commit.
Check with git status and your tests; if you get stuck, git merge --abort is safe.

Prepare Your Repository and Branches

The goal is simple: combine two branches cleanly, even when both changed the same lines of the same file. Most of the time Git merges changes on its own without asking anything. It only pauses when two branches touched exactly the same lines, and that specific case is what this guide is about.

You don't need special tools. A typical setup is a main branch and a feature branch, where someone edited line 3 on main and someone else edited line 3 on feature. When you merge them, Git has two different answers for one line, and that is where a conflict appears.

Git is installed on your computer
You are working inside a Git repository
You have two branches to merge, such as main and feature
You have a basic text editor of your choice

Understand Why Git Stops and Asks You

When two people change the same line in different ways, there is no safe way for a program to decide who is right. Lines that differ in separate places merge automatically. Only the same line changed two ways causes a conflict, which makes it a small and specific situation rather than a disaster.

Picture it this way: you set a greeting to "Hello", and your teammate set it to "Hi there". When you merge, Git compares both edits, cannot pick one, and effectively leaves a note in the file asking which greeting should win. The choice is yours to make.

Importantly, nothing is lost. Git keeps both versions side by side inside the file, so you can read them calmly and pick one, or combine them, before anything is saved. Thinking of a conflict as a question instead of an error makes the next steps far less stressful.

Different lines changed: Git merges them automatically
Same line changed two different ways: Git asks you
Both versions stay in the file until you decide

Run git merge and Read the Output

First, switch to the branch you want to merge into, in this example main. Then run git merge feature. When a conflict happens, Git prints a short report: it is auto-merging app.js, it found a merge conflict in app.js, and the automatic merge failed, so you need to fix the conflicts and commit the result.

The most useful habit at this stage is reading that output carefully. Every line starting with CONFLICT names one file that needs your attention, so you never have to search for problems yourself. If you see three CONFLICT lines, you have three files to open, and Git will not finish until all of them are resolved.

At this point you are in the middle of a merge. Git has paused and is waiting for you. Avoid starting new work now; first finish this merge or cancel it.

Confirm you are on the branch you're merging into
Write down every file named on a CONFLICT line
Don't start unrelated changes while the merge is paused

# you are on main
git merge feature
Auto-merging app.js
CONFLICT (content): Merge conflict in app.js
Automatic merge failed; fix conflicts

Find the Conflict Markers in Each File

Open each conflicted file from the list in your editor. Git has drawn three kinds of markers around the lines that clash. A quick way to jump to them is to search the file for seven less-than signs. Remember that one file can contain more than one conflict, so keep searching until you've found them all.

The first marker is a line of seven less-than signs followed by HEAD. Everything between it and the row of equals signs is your current branch's version, here main's greeting of "Hello". The row of equals signs is only a divider. It isn't code, just a fence between the two choices, and it must be removed later.

Below the divider is the incoming side: the branch you are merging in, here feature with "Hi there". The section ends with seven greater-than signs and the branch name. Once you can read these three parts, you know exactly what each side wanted.

<<<<<<< HEAD starts your current branch's version
======= separates the two versions
>>>>>>> feature ends the incoming branch's version

<<<<<<< HEAD
const greeting = "Hello";
=======
const greeting = "Hi there";
>>>>>>> feature

Edit the Code and Delete Every Marker

Now make the decision. You can keep your side, keep their side, or write a combination of both. Git doesn't mind which you choose. It only cares that the final file contains plain, working code with no marker lines left in it.

In the worked example, app.js starts with three markers. You read both options, "Hello" and "Hi there", and pick "Hi there" because that's what the team agreed on. Then you delete the marker lines so zero remain, save the file, and app.js is clean.

If the other side came from a teammate and you're not sure which version is correct, ask them. A quick message beats guessing, because choosing the wrong version can quietly undo someone else's work. And treat "zero markers left" as a strict rule: a single forgotten line of angle brackets will break your program.

Read both versions before changing anything
Keep one side, the other, or a deliberate mix
Ask the author if the code isn't yours
Search for markers one last time before saving

Stage and Commit the Resolved Files

Your files are clean, but Git doesn't know that yet. Running git add on a file is like raising your hand to say this one is done. For the example, that means git add app.js. Do this for every file that was listed as conflicted, not just the first one you fixed.

Next, run git commit. Git opens your editor with a merge message already written, which names the branch that was merged. Beginners can simply save and close the editor. If you'd rather write your own message, you can pass one with -m instead.

Git refuses to commit while any conflicted file is still unresolved, so if the commit fails, check for a file you missed. Once the commit succeeds, that single merge commit ties the history of both branches together and the conflict is officially solved.

Run git add on every file that had a conflict
Use the default merge message or add your own with -m
If the commit is refused, look for unstaged files

git add app.js
git commit
# or with a message:
git commit -m "Merge feature"

Verify That the Merge Is Really Finished

After committing, take a short moment to check rather than assuming it worked. Two signals matter: Git should report nothing left to resolve, and your code should still behave the way it did before the merge.

Run git status. When it says there is nothing to commit and the working tree is clean, no unfinished merge is hiding anywhere. Then run your tests, or simply run the app, to confirm it still works. Finally, git log should show your new merge commit at the top.

Testing matters because Git can only check the file, not the logic. Code containing the wrong choice may still look fine and run, yet behave badly. Git confirms the conflict is gone; your tests confirm the result is correct.

git status shows no conflicts and a clean working tree
Tests pass, or the app runs as expected
git log shows the merge commit at the top

Fix the Most Common Merge Conflict Mistakes

A few problems trip up almost everyone, and most come from leftover markers, missed files, or panic. None of them are serious, and each has a short, safe fix. After a couple of merges you'll recognise them immediately.

If you feel lost at any point, git merge --abort puts your branch back exactly as it was before you started merging. That means you can always stop, take a breath, and try again from a known state. Once you're comfortable, the routine is the same every time: run git merge and read, find the markers, keep the right code, add and commit, then verify.

Leftover markers: search for <<<<<<< and delete every marker line
Missed file: git status shows "both modified", so fix it and git add it
Commit refused because of unmerged files: run git add first
Panic: run git merge --abort to return to before the merge

Key takeaways

A merge conflict means two branches changed the same lines; Git needs you to choose.
Git's merge output lists every conflicted file, which is your to-do list.
The HEAD, divider and incoming markers show both versions; all markers must be deleted.
git add marks each file resolved, and git commit completes the merge.
Confirm with git status and your tests, since Git can't check your logic.
git merge --abort safely returns you to where you started.

Frequently asked questions

What causes a merge conflict in Git?

A conflict happens when two branches change the same lines of the same file in different ways. Changes to different lines merge automatically, so Git only stops when it genuinely cannot tell which edit should win.

What do <<<<<<<, ======= and >>>>>>> mean in my file?

They are conflict markers Git adds around the clashing lines. The part after <<<<<<< HEAD is your current branch's version, ======= is the divider, and the part before >>>>>>> is the incoming branch's version. Delete all of them once you've chosen the final code.

Can I keep both versions when resolving a conflict?

Yes. You can keep your side, keep the other side, or write a combination of both. Git only requires that the final file is plain, working code with every marker removed.

Why won't Git let me commit after fixing the conflict?

Usually a conflicted file hasn't been staged yet, or a file was missed. Run git status to see any files marked "both modified", fix them, and run git add on each before committing again.

How do I cancel a merge that went wrong?

Run git merge --abort. It returns your branch to exactly how it was before you started the merge, so you can try again calmly.

How do I know the merge conflict is fully resolved?

git status should show nothing to commit and a clean working tree, and git log should show the new merge commit at the top. Then run your tests or app, because a wrong choice can still look fine to Git.

Watch the full video on YouTube →

Tag

Ad