Merging and resolving conflicts

A conflict is two intentions colliding; resolve the meaning, not the markers.

A three-way merge compares each side with their merge base, the last common ancestor. Changes made on only one side apply cleanly. A conflict appears only where both sides changed the same region, and Git stops and marks it:

<<<<<<< HEAD
what your branch has
=======
what the other branch has
>>>>>>> other-branch

The markers show text, not intent. Before editing, find out why each side changed the line:

  • git log --merge -p -- FILE shows the commits on both sides that touched the file.
  • git diff --base FILE, --ours, and --theirs compare the working file with each version.
  • Commit messages and linked docs often state the constraint, for example "tool X was retired".

Frequently the right answer is neither side. One branch changed which artifact a command targets. The other changed how the command is spelled. The correct line combines both. git checkout --ours or --theirs silently discards one intention, and review tools will not flag it because no markers remain.

After resolving, run whatever the repository uses to check the file, such as tests, linters, or a release-note gate. Then git add it and commit to conclude the merge. If you get lost, git merge --abort returns to the pre-merge state.