Git Merge Conflict: How to Fix It Without Losing Your Work

You were working on your project. Maybe you pulled changes, maybe you tried to merge a branch, maybe you just clicked a button in VS Code or GitHub Desktop. And now your file is full of weird symbols you've never seen before:

<<<<<<< HEAD
const color = "blue";
=======
const color = "red";
>>>>>>> other-branch

Your code is broken. Your editor might be showing the file in strange colors. Nothing runs. It looks like something terrible happened.

Take a breath. This is a merge conflict. It's one of the most common things in git. It looks scarier than it is, and you can fix it in a few minutes once you understand what you're looking at.

What a merge conflict actually is

A merge conflict happens when git tries to combine two sets of changes and finds that both sides edited the same lines in the same file. Git doesn't know which version you want to keep, so instead of guessing and potentially destroying someone's work, it stops and asks you to decide.

Think of it like this: you and a coworker both have a copy of the same document. You change paragraph three to say one thing. They change paragraph three to say something different. Now someone needs to combine both copies into one. A human has to look at both versions and decide what the final paragraph should say. That's all a merge conflict is.

Git handles most merging automatically. If you changed paragraph three and your coworker changed paragraph seven, git combines both without any issue. Conflicts only happen when changes overlap — the same lines, in the same file, changed by two different people (or two different branches, or you and an AI tool).

What the markers mean

Those weird lines git inserted into your file are markers that show you both versions side by side. Here's how to read them:

<<<<<<< HEAD
This is YOUR version (what you had)
=======
This is the OTHER version (what you're merging in)
>>>>>>> other-branch

Three parts:

• <<<<<<< HEAD — This marks the start of the conflict. Everything between this line and the ======= is YOUR current version. "HEAD" just means "where you are right now."
• ======= — This is the divider. Your version is above it, the incoming version is below it.
• >>>>>>> other-branch — This marks the end of the conflict. Everything between the ======= and this line is the OTHER version — the changes coming in from the branch, the pull, or wherever the conflict came from.

One file can have multiple conflicts. Each one will have its own set of markers. The rest of the file — the parts that weren't in conflict — are fine and unchanged.

How to fix it

Fixing a merge conflict means doing three things:

1. Decide what the final code should be
2. Delete the conflict markers
3. Save the file and tell git you're done

You have three options for step one:

Option A: Keep your version

Delete everything from <<<<<<< through >>>>>>> and replace it with just your version:

const color = "blue";

Option B: Keep the other version

Same thing, but keep the other side instead:

const color = "red";

Option C: Combine both

Sometimes you want pieces of both. Delete the markers and write what the code should actually say:

const primaryColor = "blue";
const secondaryColor = "red";

The key thing: delete ALL the marker lines. Your file cannot have any <<<<<<<, =======, or >>>>>>> left in it when you're done. Those aren't code. If you leave them, your code won't run.

After you've fixed the file

Once every conflict in the file is resolved and all the markers are gone:

1. Save the file
2. Run git add filename (replace "filename" with the actual file) to tell git this file is resolved
3. Run git commit to finish the merge

If you're using VS Code, GitHub Desktop, or another visual tool, they'll show buttons like "Accept Current," "Accept Incoming," or "Accept Both" above each conflict. Those buttons just do what we described above — they delete the markers and keep the version you picked. You still need to commit afterward.

When merge conflicts happen

You'll run into merge conflicts in a few common situations:

Pulling when you have local changes

You made changes to a file. Someone else (or you on another computer, or an AI tool) also changed that file and pushed it. When you run git pull, git tries to combine both sets of changes and finds they overlap. Conflict.

Merging branches

You've been working on a feature branch. Meanwhile, someone made changes to the main branch. When you try to merge your branch into main (or main into your branch), git finds that both branches changed the same lines. Conflict.

Rebasing

If you or an AI tool ran git rebase, the same thing can happen — git is replaying your changes on top of new code, and when those changes overlap, you get conflicts. Rebasing can actually produce more conflicts because it replays changes one commit at a time, so you might have to resolve the same area multiple times.

AI tools editing the same files you're editing

This is the newest and most common source of merge conflicts for people building with AI tools. You're editing a file. You also ask the AI to make changes. Now there are two sets of edits to the same file, and when they get combined, you have a conflict.

Why AI makes merge conflicts worse

If you're using AI coding tools — Cursor, Copilot, Lovable, Bolt.new, Claude, ChatGPT — you'll run into merge conflicts more often, and they'll be harder to deal with. Here's why:

AI edits entire files at once

When a human makes a change, they usually touch a few lines. When an AI makes a change, it often rewrites the entire file — reformatting code, reordering functions, changing variable names, adding comments. Even if the actual meaningful change is small, the file looks completely different. Git sees every line as changed, which means almost any other edit to that file will conflict.

Instead of a neat three-line conflict you can resolve in seconds, you get a conflict that spans the entire file. Both versions look completely different. Good luck figuring out what actually matters.

AI can't see your git state

When you paste code into ChatGPT or ask Claude to fix something, the AI has no idea what branch you're on, whether you have uncommitted changes, or what other people have pushed recently. It gives you code to paste in, and if that code conflicts with changes you haven't committed yet, or changes someone just pushed, you're the one dealing with the fallout.

AI suggests force-pushing

This is the dangerous one. When you tell an AI you're having git problems, it will sometimes suggest git push --force or git reset --hard. These commands destroy work. Force-push overwrites the remote repository with your version, erasing anything other people pushed. Hard reset throws away your uncommitted changes. If you didn't have a conflict before, you definitely have a problem now — and this time, the lost work might not be recoverable.

Never run a force command unless you understand exactly what it will delete and you're sure you want to delete it. If an AI suggests force-pushing and you're not sure, don't do it.

AI "resolves" conflicts by picking one side blindly

If you paste a conflicted file into an AI and say "fix this," the AI will remove the markers and return clean code. But it's guessing which version to keep. It doesn't know what the other person's changes were supposed to do. It doesn't know your project's requirements. It just makes the syntax error go away while potentially deleting important work.

The panic factor

The first time you see a merge conflict, it feels like you've broken something. Your code is full of symbols that shouldn't be there. Your app won't run. Git is in a weird state where it says "merging" and won't let you do anything else until you deal with it.

Here's the thing: nothing is lost. Both versions of the code are right there in the file, clearly labeled. Git is showing you both sides specifically so you can choose. Your original code is the stuff between <<<<<<< and =======. The incoming changes are between ======= and >>>>>>>. Everything is still there.

If you get overwhelmed and want to start over, you can run git merge --abort to cancel the merge entirely and go back to exactly where you were before you started. Nothing is damaged. Nothing is lost. You can try again when you're ready.

Quick reference