CAD merge conflicts: what happens when two people edit the same drawing
CAD merge conflicts, explained: when two people edit the same entity, how the three-way merge flags it, and how you resolve it without losing any work.
- #merging
- #collaboration
- #version-control
- #cad
The question comes up in every demo, usually with a wince: "so what happens when we both change the same thing?" It's the right question. Fear of CAD merge conflicts is the main reason drawing teams serialize their work, one person in the file at a time, everyone else waiting. The answer is less dramatic than the fear. A conflict is a specific, detectable situation with a specific resolution step, and once you've resolved one you stop planning your week around avoiding them.
Three versions walk into a merge
When a branch comes back to the main drawing, the merge looks at three documents: the base (the version the branch split from), yours, and theirs. This is the same three-way comparison software teams have used for decades, applied to drawing entities instead of lines of text.
Having the base is the trick. Without it you can only see that two drawings differ, not who changed what. With it, every entity falls into one of three buckets:
| Situation | Verdict | What happens |
|---|---|---|
| Neither side touched it | untouched | carried through as-is |
| One side changed it | clean change | applied automatically, shown with a tint |
| Both sides changed it | conflict | a human picks, entity by entity |
Notice how narrow the last bucket is. A conflict is not "we worked on the same drawing" or even "we worked on the same area". It's the same entity, modified on both sides since the branch split. Everything else merges itself.
What CAD merge conflicts look like
Concretely: the branch moved a valve to clear a foundation, and meanwhile someone on main moved the same valve for a clash elsewhere. Or one side deleted a redundant note while the other side reworded it. Same entity, two opinions, no correct automatic answer.
In BranchCAD's merge view, those entities are flagged in amber, right on the drawing, exactly where they sit. Everything the merge handled on its own is tinted so you can audit what happened automatically instead of taking it on faith. I've seen merge tools that hide the clean changes to look smarter. That's backwards. Seeing "these 30 changes applied themselves, these 2 need you" is what builds trust in the boring 30.
Resolving one
Resolution is a choice per conflicting entity: keep mine or keep theirs. You look at the amber entity, you decide which version of reality the drawing should hold, you move to the next one. When every conflict has an answer, you commit, and the merge lands as a new version on the current branch.
Two properties of that commit matter more than the picking:
- Nothing is destroyed. The merge writes forward. Both pre-merge states are still in history, so a bad resolution is a restore away from being undone.
- The result is inspectable. The version that lands is an ordinary version: you can diff it, restore it, or branch from it like any other.
One honest limit: resolution is entity-level. If we both reworked the same polyline, one polyline wins whole; the merge won't splice our vertices together. For text that would be a weakness. For geometry I'd argue it's correct, because a machine-blended polyline is a drawing nobody drew.
Why you'll hit fewer than you expect
Drawings partition naturally. Two people on the same project are usually in different areas, different disciplines, different layers. Their entity sets barely intersect, so their merges are clean. In our own use the amber flags are rare enough to be events.
And when a conflict does appear, it's usually surfacing a coordination gap that already existed: two people were sent at the same valve with different instructions. The flag isn't the problem. It's the first tool that noticed the problem while it was still one entity wide.
Keeping them rare is mostly habit: branch small, merge often so the drift between sides stays short, and split parallel work by area when the job allows. The branching and merging pillar covers those habits in more depth, and if your team's review step is the bottleneck instead, the drawing review workflow post shows how a branch becomes the thing a reviewer approves. For a field-heavy version of all this, see how it plays out on borehole location plans.
Merging with conflict detection ships with branching on BranchCAD's Pro plan; the plans page has the breakdown. Or grab a colleague, both edit the same entity on purpose in the editor, and watch what the merge does with it. It's a five-minute experiment that ends the wincing question for good.