Skip to content
Log in
← Statistics 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: why they happen and what to do · Why two branches can clash on the same line, what GitHub shows when they do, how to read conflict markers and resolve a simple conflict in the browser, and why choosing the right text is a product decision.
  • Icons and colours: what every state means · Read pull requests, issues, checks, reviews, labels and the merge box at a glance: what every GitHub icon and colour means, and how to tell states apart by shape and text, not colour alone.
  • Merging: merge commit, squash and rebase on GitHub · What merging does, the three options behind GitHub's merge button and what each leaves in the history, fast-forward in plain words, and how to check whether a change is really in main.
  • Anatomy of a pull request: tabs, description, checks · Read a pull request page top to bottom: base and compare branches, draft and ready, the four tabs, the description, 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.