Resolve a merge conflict

A conflict means Git cannot choose a correct result automatically. It is not repository damage. It is a decision Git needs you to make.

Start with:

git status

Git lists the unmerged paths. Open one and look for markers like these:

  <<<<<<< HEAD
  Search our notes
  =======
  Find saved notes
  >>>>>>> add-search

The first section came from the current branch. The second came from the branch being merged. Read the surrounding code and write the final content you actually want. Do not keep the marker lines.

Finish or abort

Then stage the resolved file:

git add README.md
git status
git diff --staged

Staging tells Git that this path is resolved. When every conflict is resolved, complete the merge:

git commit

If you are not ready to resolve the merge, abort it before doing unrelated work:

git merge --abort

This attempts to restore the pre-merge state. Existing uncommitted changes can make restoration harder, which is why a clean working tree matters before merging.

Sometimes the right answer is neither side exactly. You might combine both changes or rewrite the line entirely. The goal is working code, not picking a winner by default.

Your editor may offer a merge tool. I still read the markers manually on small conflicts. For a one-line README change, a tool is overkill.

After the merge commit, both parent histories remain reachable. You can still inspect the feature branch commits individually with git log add-search.

If Git opens an editor for the merge commit message, the default text is usually fine. It records which branch you merged and when.

Try this on your own project: create the same line differently on two branches, merge them, resolve the conflict, and inspect the resulting merge commit with git show --stat.