A merge conflict happens when two sets of changes to the same material can’t be combined without a human decision. Version-control systems merge most concurrent changes automatically, but they stop when two people have changed the same lines differently, or when one person has edited material another has deleted.
Git shows a conflict by pausing the merge and marking the disputed passage inside the file. The lines between <<<<<<< and ======= hold one version. The lines between ======= and >>>>>>> hold the other. Someone with context resolves it by keeping one side, combining the two or writing something new, then deleting the markers and completing the merge. Platforms such as GitHub and most code editors present the same choice side by side.
Why it matters for content
The content version is familiar. Two editors open the same paragraph of an eligibility page in a system without page locking. One updates the income threshold. The other rewrites the paragraph for clarity, working from the old figure. Whoever saves last wins, and the threshold change disappears without anyone noticing. Version control would have stopped at that paragraph and asked someone to choose. Many content systems overwrite without warning. Page locking, which lets only one person edit at a time, prevents this at the cost of making others wait.
Some conflicts hide where no tool will flag them. Two copies of a policy, one on the website and one in a PDF, can drift apart without ever passing through the same merge. Martin Fowler calls the software equivalent a semantic conflict: changes that combine cleanly as text but contradict each other in meaning. These are harder to spot and depend on testing, review and a clear canonical source.
Prevention starts with that canonical source, visible ownership and version history. Teams should know who’s editing important material and how related versions, including translations and PDFs, are connected.
Conflict isn’t bad in itself. Two changes may reflect legitimate needs. Making the disagreement visible lets someone with context resolve it deliberately.
How AI changes the picture
AI systems combine information from many sources, creating an invisible form of merging. When sources disagree, a model may pick one or blend them rather than stop and report the conflict.
Configure retrieval to prefer the appropriate current source and make important disagreements visible. Dates and status help when used correctly, but a newer date doesn’t settle policy authority by itself.
AI can propose a resolution for a literal merge conflict and compare documents for contradictory claims. It can’t decide which owner has authority unless the organisation has already defined that.
Questions people ask
- Is duplication always a merge conflict?
No. Duplication can lead to contradictions, but a literal merge conflict happens only when changes are combined and the system can’t resolve them. Independent copies can disagree without ever producing that technical event.
- Can a CMS prevent conflicts?
It can lock pages, show who’s editing, warn about simultaneous changes and keep history. It can’t reconcile separate copies in other systems without governance.
- Who decides the winning version?
The relevant content owner or subject authority, informed by user needs and evidence.
- Should old versions be deleted?
Retire them from active use while keeping history where records or accountability require it.
Learn more
- Merge conflicts – GitHub’s explanation of changes it cannot combine automatically, including concurrent edits and edit-versus-delete cases.
- Basic Branching and Merging – a chapter of the free Pro Git book showing what conflict markers look like in a file and how to resolve them.
- Semantic Conflict – Martin Fowler’s 2011 note on changes that merge cleanly as text but clash in meaning, and why integrating often helps.