How to Resolve Git Merge Conflicts: A Practical Guide

Git merge conflicts can feel like two cats fighting over the same keyboard. One branch says, “Use my code.” Another branch says, “No, use mine.” Git stands in the middle and says, “Human, please help.” Good news. Merge conflicts are normal. They are not a disaster. They are just Git asking you to choose the best version.

TLDR: A Git merge conflict happens when Git cannot automatically combine changes from two branches. To fix it, open the conflicted files, look for the conflict markers, choose the code you want, then save the file. After that, stage the fixed files and commit the merge. Stay calm, read carefully, and test your code before you celebrate.

What Is a Git Merge Conflict?

A merge conflict happens when Git sees two changes in the same place and cannot decide what to keep.

Imagine two people editing the same sentence.

• Alice writes: The button should be blue.
• Bob writes: The button should be green.

Git does not know which color is correct. So it pauses the merge. It marks the problem area. Then it waits for you.

This is not Git being broken. This is Git being careful. It does not want to throw away someone’s work by accident.

When Do Merge Conflicts Happen?

Conflicts usually happen during a merge, rebase, pull, or cherry pick.

The most common case is this:

1. You create a branch.
2. Your teammate creates another branch.
3. You both edit the same file.
4. You both edit the same lines.
5. Someone tries to merge.
6. Git sighs dramatically.

Git can merge many changes by itself. It is pretty smart. But it cannot read minds. Not yet. Probably for the best.

Step 1: See What Happened

First, run this command:

git status

This tells you which files are in conflict. Git may show something like this:

Unmerged paths:
  both modified:   index.html
  both modified:   styles.css

This means those files need your attention. Treat them like tiny fires. Not scary fires. More like toaster fires. You can handle them.

You can also see which branch you are on:

git branch

This helps you avoid fixing conflicts in the wrong place. That is a classic “oops” moment.

Step 2: Open the Conflicted File

Open one conflicted file in your code editor.

You will see special conflict markers. They look like this:

<<<<<<< HEAD
This is your current branch version.
=======
This is the incoming branch version.
>>>>>>> feature-branch

These markers are Git’s way of saying, “Here are the two versions. You pick.”

• <<<<<<< HEAD starts your current version.
• ======= separates the two versions.
• >>>>>>> branch-name ends the incoming version.

Important: The markers must be removed before you finish. Do not leave them in your code. They are not decorations. They are warning signs.

Step 3: Choose What to Keep

Now comes the human part.

You must decide what the final code should look like. You have a few choices.

• Keep your version.
• Keep the incoming version.
• Combine both versions.
• Write a new version.

Here is a simple example.

<<<<<<< HEAD
<h1>Welcome to our website</h1>
=======
<h1>Welcome to our awesome website</h1>
>>>>>>> feature-homepage

You might choose this final version:

<h1>Welcome to our awesome website</h1>

Or maybe this:

<h1>Welcome to our very awesome website</h1>

Git does not care which one you pick. Git just wants a clean file.

Step 4: Remove the Conflict Markers

This step is easy to forget. Do not forget it.

After you choose the final code, remove all of these:

• <<<<<<<
• =======
• >>>>>>>

If you leave them in, your app may break. Your team may cry. Your linter may scream.

Before you move on, search the file for <<<. If you find it, the conflict is not fully fixed.

Step 5: Test the Code

Do not commit yet. First, test.

Run your usual checks. For example:

npm test

Or:

pytest

Or:

go test ./...

Use whatever makes sense for your project.

Also run the app if you can. Click around. Try the page. Use the feature. Make sure the code still behaves.

A conflict can be syntactically fixed but logically wrong. That means the code runs, but the result is silly. Like a login button that logs you out. Very rude.

Step 6: Stage the Fixed Files

When the conflict is fixed, tell Git:

git add index.html

If you fixed many files, you can stage them one by one. This is safer.

git add styles.css
git add app.js

You can also stage everything:

git add .

But be careful. This may add files you did not mean to include. Git is powerful. So is a blender. Use both with attention.

Step 7: Commit the Merge

Now run:

git commit

Git may create a merge commit message for you. You can keep it. Or you can make it clearer.

For example:

Resolve merge conflict in homepage files

If you were in the middle of a rebase, the command may be different:

git rebase --continue

Git will continue the rebase. If more conflicts appear, repeat the same process. Yes, sometimes Git gives you another one. Like a bonus puzzle. Lucky you.

Useful Commands During a Conflict

Here are some helpful commands. Keep them near your keyboard. Or tattoo them on a rubber duck.

• git status shows conflicted files.
• git diff shows changes that still need work.
• git add file marks a conflict as resolved.
• git commit finishes a merge.
• git rebase --continue continues a rebase.
• git merge --abort cancels a merge.
• git rebase --abort cancels a rebase.

Abort does not mean failure. It means “I need to step back.” Sometimes that is smart. Especially if the conflict is huge and your coffee is empty.

How to Use a Merge Tool

You do not have to fix conflicts by hand. Many editors have visual merge tools.

Tools like VS Code, IntelliJ, and other editors show buttons such as:

• Accept Current Change
• Accept Incoming Change
• Accept Both Changes
• Compare Changes

These buttons are friendly. They help you see both versions side by side.

In VS Code, open the conflicted file. You will see options near the conflict. Click the one you want. Then review the result. Do not click wildly. This is not a video game boss fight.

Common Mistakes to Avoid

Merge conflicts are simple. But simple things can still bite.

• Do not delete code blindly. Read both versions first.
• Do not keep conflict markers. They will break things.
• Do not skip tests. Tests catch sneaky bugs.
• Do not resolve conflicts when tired. Sleepy humans make spicy mistakes.
• Do not panic. Git is loud, not evil.

If you are unsure, ask the person who wrote the other change. A five minute chat can save an hour of confusion.

How to Prevent Merge Conflicts

You cannot avoid all conflicts. But you can reduce them.

• Pull often. Keep your branch fresh.
• Make small changes. Small branches merge more easily.
• Commit often. Good checkpoints help you recover.
• Talk to your team. Avoid editing the same big file at once.
• Review before merging. Catch problems early.

A good habit is to update your branch before opening a pull request.

git checkout feature-branch
git pull origin main

Or, if your team uses rebase:

git fetch origin
git rebase origin/main

Ask your team which style they prefer. Merge and rebase are both useful. The best one is the one your team agrees on.

A Tiny Real World Example

Let us say you are on a branch called feature-login. You want to merge main into it.

git checkout feature-login
git merge main

Git says there is a conflict in login.js.

You run:

git status

You open login.js. You find the conflict markers. You choose the correct final code. You remove the markers. You save the file.

Then:

npm test
git add login.js
git commit

Done. You have defeated the conflict goblin.

Final Thoughts

Git merge conflicts look scary at first. But they follow a simple pattern. Find the file. Read the markers. Choose the final code. Remove the markers. Test. Stage. Commit.

The main secret is to slow down. Conflicts are not a race. They are a conversation between branches. Your job is to listen, choose wisely, and keep the project healthy.

So the next time Git stops and asks for help, do not panic. Take a breath. Open the file. Fix the conflict. Then enjoy that sweet, sweet clean working tree.