A merge conflict happens when Git cannot automatically combine two sets of changes because both edited the same lines of the same file. Instead of guessing which version you want, Git stops and asks you to decide. It feels alarming the first time, but it is a normal part of working with other people on shared code, and resolving one is a calm, mechanical process once you know what the markers mean.
Why merge conflicts happen
Git is excellent at merging changes that touch different parts of a file. Two people editing two unrelated functions merge cleanly with no conflict. The trouble starts when two branches change the same lines, or one branch edits a line another branch deleted. Git has no way to know whether you want one version, the other, or a blend, so it pauses and hands the decision to you.
Conflicts are most common when a branch lives a long time and drifts far from the main line, when two people work the same file, or when an automated formatter rewrites large regions. Smooth collaboration like this is part of becoming a web developer, where shared Git workflows are a daily reality.
How Git marks a conflict
When a conflict occurs, Git edits the file in place and inserts markers showing both versions:
<<<<<<< HEAD
const greeting = "Hello there";
=======
const greeting = "Hi!";
>>>>>>> feature-branch
The top block between <<<<<<< and ======= is your current branch. The bottom block between ======= and >>>>>>> is the incoming branch. Your job is to edit this region into the single correct result and delete all three marker lines.
How to resolve one, step by step
- Run the status command.
git status lists every conflicted file so you know the scope.
- Open each conflicted file and find the marker blocks.
- Decide the correct content. Keep your version, keep theirs, or combine them by hand. Read both before choosing.
- Remove the markers. Delete the
<<<<<<<, =======, and >>>>>>> lines so the file is clean code again.
- Stage the resolved file with
git add, then run your tests to make sure the result actually works.
- Complete the merge by committing, or by continuing the rebase if you were rebasing.
-- typical resolution flow
git status -- see conflicted files
-- edit files, remove markers
git add resolved_file.js
git commit -- finishes a merge
Merge versus rebase conflicts
| Aspect |
During a merge |
During a rebase |
| When conflicts appear |
All at once at merge time |
One commit at a time |
| Continue command |
git commit |
git rebase --continue |
| Abort and undo |
git merge --abort |
git rebase --abort |
| Resulting history |
Keeps a merge commit |
Replays commits linearly |
Either way the in-file resolution is identical. The only difference is how Git walks through the conflicts and how you tell it to continue.
How to avoid the worst conflicts
- Merge or pull often. The longer a branch drifts from main, the bigger the eventual conflict.
- Keep branches focused and short-lived. A branch that changes one thing conflicts less than one that touches everything.
- Agree on formatting. A shared formatter run by everyone stops noise conflicts caused by reformatting.
- Communicate on shared files. If two people must edit the same file, coordinate so you are not fighting over the same lines.
What to skip
- Panicking. A conflict does not lose your work; both versions are right there in the file.
- Blindly accepting one side. "Accept incoming" or "accept current" buttons are convenient but can silently drop a needed change. Read both blocks first.
- Committing with markers still in the file. Leaving
<<<<<<< lines in produces broken code. Always confirm the file is clean and tests pass.
FAQ
Does a merge conflict mean I did something wrong?
No. It simply means two branches changed the same lines and Git needs a human to decide. It is a normal part of collaboration.
Can I undo a merge that has conflicts?
Yes. Run git merge --abort to return to the state before the merge, or git rebase --abort if you were rebasing. Nothing is lost.
What do the conflict markers mean?
The block above the ======= line is your current branch, and the block below it is the incoming branch. You edit the region into the correct result and delete all the marker lines.
How do I avoid conflicts in the first place?
Merge from the main branch frequently, keep branches small and short-lived, and agree on a shared formatter so reformatting does not cause noise.
Where to go next
See what a pull request is, how to write a good commit message, and GitHub versus GitLab compared.