Resolve a Git merge conflict

A conflict means Git cannot automatically determine the intended result. Conflicts can involve overlapping edits, deletions, renames, file types, or binary files—not only two changes to the same line. Start with git status and resolve each affected path deliberately.

Read a text conflict

<<<<<<< HEAD
Content from the current side
=======
Content from the incoming side
>>>>>>> feature-x

For an ordinary merge, the first section corresponds to the current branch and the second to the branch being merged. Replace the entire marked region with the correct final content. The result may combine both sides or use different code altogether. Other conflict styles can also show a common-ancestor section.

Finish an ordinary merge

git merge feature-x
git status
# Edit the conflicted files and test the intended result.
git add -- src/app.js
git diff --cached
git diff --cached --check
git status
git commit

git diff --cached --check checks the staged patch for conflict markers and whitespace errors. Staging tells Git you resolved a path; it does not prove the resolution is correct. Use git rm -- path when deletion is the intended resolution. Check all unmerged entries before completing the operation, and run the relevant tests.

Use tools or select a whole side

An editor's merge UI can display the current and incoming versions, while git mergetool launches a configured merge tool. “Accept both” concatenates choices according to the tool; it does not establish that the combined program is valid.

For an ordinary unmerged file:

git checkout --ours -- path/to/file
git add -- path/to/file
# Alternative choice: git checkout --theirs -- path/to/file

These select an entire side, potentially discarding useful edits from the other one. Some delete conflicts have no file at the selected stage. During rebase, the meaning of ours and theirs differs from the intuitive “my branch/their branch” interpretation: ours is the rebased-onto side and theirs is the commit being replayed. Inspect the actual content before choosing.

Abort or continue the right operation

git merge --abort attempts to return an in-progress merge to its previous state. Pre-existing uncommitted changes can make complete restoration difficult, so preserve important work first.

For a rebase conflict, edit and stage the resolution, then run git rebase --continue. More commits may conflict afterward. Use git rebase --abort to abandon that operation. A cherry-pick has its own continue and abort commands; do not substitute git commit indiscriminately.

Review the finished result

After a merge, compare the result to each parent with git diff HEAD^1 HEAD and git diff HEAD^2 HEAD. Ordinary combined git show output may omit changes that are not different from every parent. A branch review such as git diff origin/main...HEAD answers a different question: changes from a merge base to HEAD.

Repeated conflicts often indicate long-lived overlapping work. Smaller changes, regular integration, and separating broad formatting edits can reduce the burden, but semantic conflicts can still exist even when Git reports a clean merge.

See git-merge, git-checkout conflict stages, and git-rebase.