Skip to content
Log in
← Glossary

merge conflict

Also called: conflict, conflicts

A situation where two branches changed the same lines differently, so Git cannot combine them automatically and a person has to choose the result.

When Git merges two branches, it compares each side with the commit where they split. Changes in different places are combined automatically. When both sides changed the same lines in different ways, Git can't know which version is right, stops and marks the spot in the file: <<<<<<< your side, =======, the other side, >>>>>>>. A person decides the result, removes the markers and finishes the merge. On GitHub, simple text conflicts can be resolved in the browser with Resolve conflicts.

Example

Two branches changed the same free-delivery line on CatChow's delivery page: one to 800 UAH, the other to 1000. The second pull request reports a conflict, the team agrees on 1000, and Emma resolves it in the browser.

Common mistakes

Treating a conflict as an error to click away. It is a question only people can answer; a merge without conflicts can still be wrong when two changes in different files contradict each other.

Learn it in the course

  • Merge conflicts on GitHub: why they happen and what to do · What a merge conflict on GitHub is and why two branches can clash on the same line, what "This branch has conflicts that must be resolved" means, how to read conflict markers and resolve a simple conflict in the browser, and why choosing the right text is a product decision.
  • Icons, colours and checks: what every GitHub state means · Read pull request status, issues, GitHub checks, reviews, labels and the merge box at a glance: what every icon and colour means, merged vs closed, and how to tell states apart by shape and text, not colour alone.
  • Merging on GitHub: merge commit, squash and merge, rebase · What merging does, the three options behind GitHub's merge button (merge commit, squash and merge, rebase and merge) and what each leaves in the history, a fast-forward merge in plain words, and how to check whether a change is really in main.
  • What is a pull request? Anatomy of a PR page · What a pull request is, read top to bottom: base and compare branches, draft and ready, the four tabs, the description and a pull request template, reviewers and labels, linked issues, checks and the merge box.
  • GitHub flow: small branches, fast merges · The loop most product teams work in: branch from main, pull request, review and checks, merge, deploy. Why small, short-lived branches are safer, what "merged" and "deployed" mean, how feature flags let unfinished work ship hidden, and how to read a feature's progress from the pull request list.