Merge conflict
Also known as: Git merge conflict, merge conflicts, conflict resolution (Git)
A merge conflict occurs when version control software such as Git tries to combine changes from different branches but finds that the same lines of a file were changed in different ways.
Since the software can't know which version is right, it pauses and marks the conflicting sections for a person to resolve. While merge conflicts can be stressful, they're a normal part of teamwork, and small, frequent merges make them rare and easy.
Merge conflict, explained at three levels
At home
A merge conflict is like two people editing the same sentence in a shared document at the same time, each in a different way. Edits to different parts of a file combine on their own. When both people changed the exact same lines, though, the software cannot guess which version is right, so it stops, marks both versions side by side and waits for a person to choose.
At work
A merge conflict happens when version control tries to combine two developers' work and finds that both changed the same lines differently. The software pauses and marks the clash so someone can decide what the final code should say. Businesses care because conflicts cost time and can introduce bugs, and they grow when people work separately for too long before combining their changes.
At home
Git can combine most changes automatically, because it compares each branch with their common starting point and applies both sets of edits. A conflict happens only when both branches changed the same lines differently, or one deleted a file the other edited. Git cannot know which version you want, so it stops and marks the spot in the file: your version between '<<<<<<<' and '=======', the other version between '=======' and '>>>>>>>'. You decide, remove the markers, and commit.
At work
Conflicts grow with time and overlap. Long-lived branches drift further from main, so merging main into them, or rebasing frequently, keeps conflicts small. Formatting tools run automatically remove trivial whitespace and style conflicts. Clear code ownership and small pull requests reduce collisions. Editors such as Visual Studio Code show conflicts with buttons to accept either side or both, and Git's rerere setting can remember how you resolved a conflict and reapply it.
At home
When a conflict looks overwhelming, you are never stuck. 'git merge --abort' or 'git rebase --abort' returns everything to exactly how it was before you started, with nothing lost. You can then update your branch in smaller steps or ask the other person what they changed. In my view, knowing that escape hatch makes Git far less scary, because a conflict is a question, not a disaster.
At work
A clean merge is not proof of correct code. Two changes can merge without textual conflict yet break each other, such as one branch renaming a function another branch starts calling, so run the full test suite after every merge or resolution. Review conflict resolutions in pull requests, especially AI-suggested ones, which may silently drop one side's logic. Merge queues test each change against the latest main before merging, preventing these semantic conflicts from reaching production.
Real-world examples
At home
Lena and a classmate both edited the same function in their group project. Git flagged a merge conflict, and they combined the best parts of each version.
At work
Jerome leads a Saskatoon development team. After constant merge conflicts, he switched the team to smaller daily merges, and conflicts almost disappeared.
Common confusions
- A merge conflict means someone made a mistake. — It just means two valid changes touched the same lines. It's a normal part of collaboration.
- If Git merges without conflicts, the code works. — Changes can combine cleanly yet still break each other. Tests are still needed.
For analysts
When teams complain about merge conflicts, I'd look at branch lifespans and work allocation. Process fixes usually work better than tool changes.
History & origin
Merge conflicts have existed as long as people have edited shared files. Early version control systems avoided them by locking files so only one person could edit at a time. CVS and Subversion allowed simultaneous editing with merging, and Git, from 2005, made branching and merging easy and frequent. Visual merge tools in editors such as Visual Studio Code made conflicts easier to resolve, and practices such as trunk-based development and continuous integration encouraged merging small changes often. AI coding assistants began suggesting conflict resolutions in the mid-2020s. In my view, frequent merge conflicts are usually a sign of process problems, not tool problems.