Conflicts

Why

You merge a teammate's branch, and Git stops halfway and prints CONFLICT. That happens in any team where more than one person touches the code. No need to panic: Git hasn't broken anything, it just can't decide for you which version of the lines is correct. This lesson is about calmly finishing a merge or rebase like that, or backing out of it.

When a conflict happens

Git merges changes on its own when they don't overlap. You changed the first 10 lines of a file, your teammate changed the last 50, and Git stitches them together without asking.

A conflict happens when the same lines (or neighboring ones) were changed both in your branch and in the one you're merging in. Git doesn't know whose version is correct, so it stops and asks you to decide.

The most common conflict spots:

• package.json, go.mod, requirements.txt: the dependency block;
• CHANGELOG.md: everyone appends new lines at the top;
• config files that you and a parallel branch both edit.

What it looks like in the terminal

git merge feature/login

Auto-merging f.txt
CONFLICT (content): Merge conflict in f.txt
Automatic merge failed; fix conflicts and then commit the result.

The merge isn't finished: there's no commit yet, Git is waiting for you. Everything that merged without conflicts is already sitting in your working directory and the index.

What shows up in the file

At the conflict spot, Git inserts markers:

common code
<<<<<<< HEAD
your version (what's in your current branch)
=======
their version (what's in the branch you're merging in)
>>>>>>> feature/login
more common code

• <<<<<<< HEAD opens your block;
• ======= separates the two versions;
• >>>>>>> feature/login closes the other block and signs it with the branch name.

During git rebase the sides swap. HEAD there isn't your branch, it's the one you're moving the commits onto (upstream). The bottom block is your commit, and the signature after >>>>>>> shows its short hash and message instead of a branch name, for example >>>>>>> e4aa505 (feat).

While the markers are in the file, the file is broken: it's invalid code in any language. You can't run it until you resolve the conflict.

How to resolve it

1. Open the file and decide what to keep: your version, theirs, or both together. Sometimes the right answer is to rewrite the chunk from scratch with both edits in mind.
2. Remove all three markers (<<<<<<<, =======, >>>>>>>) and any extra lines.
3. Tell Git the conflict is resolved: git add <file>.

Once every conflicted file is added, continue the operation:

# if it was a merge
git commit                # Git will fill in the message Merge branch '...' for you
# if it was a rebase
git rebase --continue

git commit without -m opens an editor with the message already filled in. Save and close it (in vim that's :wq). If you don't need the editor, use git commit --no-edit.

git add doesn't check whether markers are still in the file. It accepts a file with <<<<<<< inside just fine, so before add make sure there are no markers left (how to do that is below, in "Trap: a marker in the commit").

git status during a merge

An unfinished merge shows up in git status as its own section:

git status

On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   src/app.ts
	both modified:   src/config.ts

both modified means both branches changed the file and it has markers in it. After git add <file> it disappears from Unmerged paths: the resolution is counted. Once every file is resolved, git status prints All conflicts fixed but you are still merging. and suggests git commit.

During a rebase the first line is different: interactive rebase in progress; onto <hash>, and the hints mention git rebase --continue, --skip and --abort.

If resolving isn't going well

Roll everything back:

git merge --abort     # if it was a merge
git rebase --abort    # if it was a rebase

After that the repository is back in the state it was in before the merge or rebase started, and you can start over. This is an emergency exit, and you can use it without worry.

Mergetool

When there are many conflicts or they're confusing, it helps to open a visual mergetool. It shows three panels (your version, the common ancestor, their version) and lets you pick lines with the mouse.

git mergetool

At work you'll most likely resolve conflicts in an IDE: VS Code, IntelliJ, and the like. They highlight conflict blocks and show buttons above each block. In VS Code that's Accept Current Change, Accept Incoming Change, Accept Both Changes, and for tricky cases there's a 3-way merge editor.

Trap: a marker in the commit

Here's how it happens: you resolve two conflicts out of three, forget about the third, and run git add . && git commit. A file with <<<<<<< inside rides into the commit. CI usually catches this (tests fail, the linter complains), but sometimes the file slips through and production breaks.

How to catch it:

• grep -rn '<<<<<<<' . from the repository root;
• git diff --check before git add: it prints lines like f.txt:2: leftover conflict marker;
• git diff --cached --check after git add, before the commit. A plain git diff --check stays silent at that point: it compares the working directory with the index, and the file is already in the index;
• the language's linter and the IDE flag markers as an error right away.

In a team, it's worth setting up a pre-commit hook or a CI check that explicitly fails a commit or MR with markers.

Common mistakes

• Deleting a whole block along with the change you needed. For example, both branches added a dependency, and you kept only yours. Before git add, reread the file: every change you need should still be there.
• Removing <<<<<<< and >>>>>>> but forgetting the ======= in the middle.
• Running git commit -am in the middle of a rebase. During a rebase, after git add you need git rebase --continue, not a new commit.
• Mixing up the sides during a rebase and keeping the wrong version. Remember that during a rebase, HEAD is the branch you're moving commits onto.
• Deciding to "start clean" with rm -rf and a new clone. git merge --abort or git rebase --abort is enough.

What you'll need for the tasks

• git status, git log --oneline --graph --all
• git diff --check, git diff --cached --check, grep -rn '<<<<<<<' .
• git add <file>, git commit --no-edit
• git rebase <branch>, git rebase --continue, git merge --abort, git rebase --abort
• the -C <folder> flag: run a Git command against a repository in another folder (from the lesson on branches)

Next is a short quiz, and that wraps up Git.