One of the first questions people ask when I show branching in CAD is usually some version of:

"But what happens if we both change the same thing?"

It's a very good question.

In fact, I think it's one of the questions any serious collaborative CAD system should be able to answer clearly.

If two people are editing the same drawing, eventually they will make changes that overlap.

Maybe two engineers move the same valve.

Maybe one person deletes a note while another edits it.

Maybe two designers modify the same boundary or detail.

The easy answer is to prevent people from working in parallel.

That's how many drawing teams have traditionally handled it:

One person edits. Everyone else waits.

It avoids conflicts, but it also creates a different problem: people become the coordination mechanism.

Modern version-control systems take a different approach.

Let people work independently.

Detect overlapping changes.

Show the conflict.

Let a human decide what the final version should be.

That idea is already established in software development, and it is increasingly relevant to CAD as well.

Onshape, for example, has long supported branching and merging as part of its version-management model. Its current documentation describes branches, versions, merge lines and workflows for merging branch changes back into protected workspaces.

BranchCAD takes the same general version-control idea and applies it to a different problem: collaborative 2D CAD and drawing workflows.

The interesting part isn't the word "branch."

The interesting part is what happens when branches disagree.

What is a CAD merge conflict?

A CAD merge conflict occurs when two versions of a drawing have both changed the same underlying entity since they diverged.

For example:

You create a branch from the current drawing.

You move a valve 100 mm to clear a foundation.

Meanwhile, someone else continues working on the main drawing and moves that same valve because it conflicts with another service.

Now there are two legitimate changes.

Neither one can safely be applied without considering the other.

That's a conflict.

Notice what a conflict is not.

It isn't:

• two people editing the same drawing
• two people working on the same project
• two people working in the same area
• two people making changes at the same time

The important question is much narrower:

Did both sides change the same entity after the branch was created?

That distinction is what makes automated conflict detection practical.

Why traditional CAD teams try to avoid conflicts

Most traditional CAD workflows were not designed around parallel editing.

The common solution is coordination.

"Don't open that drawing yet."

"I'm working on the architectural plan."

"You can edit it after I finish."

"Save it as Rev B."

"Make sure you're using the latest file."

This works surprisingly well when a team is small and projects are simple.

It becomes harder as the number of people and revisions increases.

Eventually, the team starts creating rules around the software:

• one person edits at a time
• files are locked manually
• revisions are copied into folders
• people rename files to indicate status
• PDFs are emailed for review
• changes are merged manually by a person

The software hasn't really solved collaboration.

The team has built a human process around the limitations of the software.

That process can work.

It can also consume a lot of time.

The three versions behind a CAD merge conflict

The easiest way to understand a merge is to think about three versions.

1. The base

This is the version where the two lines of work diverged.

Imagine the original drawing contains a valve at location A.

You create a branch from that version.

At that moment, both sides agree.

That is the base.

2. Your version

You move the valve because you need clearance around a foundation.

3. Their version

Meanwhile, someone working on the main drawing moves the same valve because of a different coordination issue.

Now the system has three pieces of information:

Base: valve at A

Your version: valve at B

Their version: valve at C

There is no reliable way for the software to decide whether B or C is correct.

That's where a human needs to make the decision.

What happens to everything that doesn't conflict?

This is one of the most important parts of the model.

Imagine the drawing contains 5,000 entities.

You changed 20.

Someone else changed 30.

Only two of those changes overlap.

You don't want a system to stop and ask a human to manually reconcile all 50 changes.

Most of them are perfectly safe.

A useful merge process should therefore separate changes into categories.

The last category is the conflict.

Everything else can move forward automatically.

That distinction matters because a merge conflict should be an exception, not the workflow.

What a CAD merge conflict looks like

Consider a simple example.

The original drawing contains a pipe.

You create a branch and move the pipe 200 mm to the left.

At the same time, another designer moves that same pipe 150 mm to the right on the main drawing.

When you eventually try to merge your branch, the system sees:

Base: original pipe

Branch: pipe moved left

Main: pipe moved right

There is no mathematically correct answer.

The system shouldn't guess.

It should tell you:

These two changes conflict.

That is the point where a person decides what the drawing should contain.

Why automatic conflict resolution isn't always a good idea

It is tempting to think that a clever enough algorithm should simply combine everything.

Sometimes it can.

Sometimes it shouldn't.

Imagine two people editing the vertices of the same polyline.

A system could theoretically attempt to combine their edits.

But what would the resulting geometry actually mean?

It might be mathematically valid.

It might also be a shape that neither engineer intended to draw.

For CAD, that distinction matters.

A drawing isn't just a collection of coordinates.

Geometry represents design decisions.

When two people have made contradictory decisions about the same entity, I would rather have the software stop and ask a human than silently create a third version that nobody intended.

That is one reason BranchCAD currently treats conflicting geometry conservatively.

If the same entity has conflicting changes, a person decides.

How conflict resolution works

The resolution process should be deliberately boring.

That's a compliment.

You want the system to tell you:

"These are the two things you need to decide."

Then you inspect the geometry and choose the appropriate result.

In BranchCAD's current merge workflow, conflicting entities are identified in the merge view so the reviewer can make the decision rather than having the software silently overwrite one side.

Once every conflict has been resolved, the merge can be committed as a new version.

The important thing is that the previous states remain part of the history.

A bad decision isn't supposed to erase the work that came before it.

Nothing should disappear when you resolve a conflict

This is one of the principles I think matters most in version-controlled CAD.

Suppose you choose the change from the main branch.

That doesn't mean the other person's work should disappear from history.

You should still be able to understand:

• what the branch contained
• what the main drawing contained
• what the conflict was
• which option was selected
• what the resulting version contains

That's fundamentally different from replacing one DWG file with another.

With files, the history often exists somewhere outside the drawing.

With a version-controlled workflow, the history is part of the workflow itself.

CAD merge conflicts aren't the same as file conflicts

This distinction is important.

Traditional file-based workflows often produce conflicts at the file level.

You might have:

site-plan-final.dwg

and

site-plan-final-revised.dwg

The problem isn't necessarily that the geometry conflicts.

The problem is that you now have two files and need a person to figure out which changes belong in the final drawing.

Entity-level version control is a more precise model.

Instead of asking:

"Which file should we keep?"

you can ask:

"Which changes should become part of the next version?"

That is a much better question.

Why most changes won't actually conflict

At first, people often imagine that collaborative CAD means constant conflicts.

In practice, drawings are naturally divided.

One person may work on:

• architectural geometry

while another works on:

• services

and another works on:

• dimensions and annotations.

Even within the same discipline, people often work on different parts of a drawing.

That means most changes don't overlap.

The important thing isn't to eliminate the possibility of conflict.

It's to make conflicts:

rare, visible, understandable, and recoverable.

That's a much more realistic goal.

The bigger benefit: you don't have to coordinate every edit

This is where I think branching becomes more interesting than the merge itself.

The goal isn't to create a sophisticated system for resolving conflicts.

The goal is to make it safe for people to work independently.

If every change requires someone to ask:

"Are you using this drawing?"

then collaboration remains dependent on communication.

If the system can safely separate changes, people can work more independently.

That's a significant difference.

Instead of:

"Wait until I'm finished."

you can have:

"Make your change. I'll merge it when it's ready."

How to reduce CAD merge conflicts

You don't need to eliminate conflicts completely.

You can also reduce how often they occur.

A few simple practices help.

Keep branches focused

A branch containing one well-defined change is easier to review and merge than a branch containing three weeks of unrelated work.

For example:

Good

Update retaining wall detail.

Harder to manage

Update retaining wall + revise site plan + change drainage + modify title block + clean up annotations.

Small branches make the history easier to understand.

Merge regularly

The longer two branches remain separate, the more they can diverge.

If the main drawing changes every day while a branch remains untouched for three weeks, the eventual merge has more potential for conflict.

Shorter-lived branches generally make reconciliation easier.

Separate independent work

If two people can work on different parts of the drawing without interfering with each other, let them.

Parallel work is the reason to have branching in the first place.

Review before merging

A merge should not simply mean:

"The software says this can be merged."

A good workflow is:

Change → inspect → review → resolve conflicts → merge.

The software handles the bookkeeping.

The engineer still makes the decision.

What about Onshape?

This is worth addressing directly because Onshape is one of the clearest examples of branching and merging in commercial CAD.

Onshape's current documentation describes a version graph with branches and versions, and its platform includes branch-and-merge functionality for exploring independent design work and bringing a preferred result back into the main project.

Onshape also provides workspace protections where changes to a protected workspace are made through branches and merged back into the protected workspace.

So if someone asks:

"Does any other CAD software have branching?"

the honest answer is yes.

Onshape is an important example.

The distinction is what the software is built around.

Onshape is primarily a cloud-native 3D CAD/PDM platform, with branching and merging integrated into that broader product-development environment.

BranchCAD is much narrower.

It is focused on 2D CAD and drawing workflows, where the problem is often not complex 3D product configuration but revisions to plans, layouts, details, annotations and engineering drawings.

That is an important difference.

The goal isn't to claim that BranchCAD invented branching for CAD.

The goal is to make version-control concepts practical for people who live in 2D CAD.

BranchCAD vs traditional 2D CAD

Traditional desktop CAD remains extremely capable.

If you need decades of accumulated commands, plugins, specialist workflows and integrations, traditional CAD has major advantages.

It also works very well for a single person working locally on a drawing.

The weakness isn't necessarily the drafting engine.

It's everything around collaboration.

A traditional workflow often looks like:

DWG → copy → edit → save → PDF → email → markup → edit again

A version-controlled workflow can look more like:

Main → branch → edit → diff → review → resolve → merge

Neither approach is automatically correct for every company.

But the second approach gives teams a much clearer model for parallel work.

BranchCAD vs other online CAD software

The phrase online CAD software covers a surprisingly wide range of products.

Some are essentially lightweight drawing editors.

Some focus on 3D modelling.

Some are browser versions of established desktop CAD products.

Some focus heavily on collaboration.

Some are designed primarily for viewing and markup.

So I wouldn't recommend choosing software simply because it is "online."

Instead, ask what happens when the second person enters the workflow.

Can they:

• edit independently?
• create a version?
• see what changed?
• review the change?
• comment on it?
• resolve conflicting changes?
• understand the history?
• restore an earlier version?

Those questions tell you much more about collaborative CAD maturity than the word "cloud."

What BranchCAD is trying to do differently

BranchCAD isn't trying to reproduce every feature of the largest CAD platforms.

The focus is narrower:

2D CAD + collaboration + version control.

That means features such as:

• branching
• version history
• visual differences
• drawing review
• geometry-based comments
• merging
• conflict detection

are not secondary features bolted onto a drafting application.

They are part of the workflow we're trying to build.

There is also a practical reason for keeping the scope narrow.

A small engineering company doesn't necessarily need a giant product-development platform.

It may simply need a better way for three people to work on the same 2D drawings without emailing files back and forth.

That's the problem BranchCAD is designed to address.

Frequently asked questions about CAD merge conflicts

What is a CAD merge conflict?

A CAD merge conflict happens when two versions of a drawing have both changed the same entity since they diverged.

The system cannot safely decide which change should win, so it asks a person to resolve the conflict.

Does CAD support branching?

Yes.

Branching and merging are already available in CAD products, most notably Onshape. Onshape's documentation explicitly describes creating branches, comparing versions and merging branches back into a main workspace.

BranchCAD applies the concept specifically to collaborative 2D CAD workflows.

Is Onshape the only CAD software with branching?

No.

It would be inaccurate to make that claim.

Onshape is a prominent example of CAD software with branching and merging, particularly in cloud-native 3D CAD.

The more interesting question is which CAD products provide branching in a workflow that makes sense for 2D drawing teams.

Can two people edit the same CAD drawing at the same time?

It depends on the CAD system.

Some systems are designed for concurrent collaboration.

Others rely on file locking or coordination to prevent simultaneous conflicting edits.

A branching workflow takes a different approach: people can work independently and conflicts are detected when the changes are brought back together.

What happens if two people move the same line?

A good version-control system should recognize that both sides changed the same entity and flag it as a conflict.

It should not silently choose one change.

The user then decides which result is correct.

Can CAD merge conflicts be automatically resolved?

Some changes can be merged automatically.

If only one side changed an entity, there is generally no reason to ask a person to choose.

When both sides changed the same entity, automatic resolution becomes much less reliable.

For geometry, conservative conflict detection is often preferable to silently generating a result that neither designer intended.

Will CAD branching eliminate the need for file naming and revision control?

It can reduce a lot of manual file management, but it doesn't eliminate the need for proper document-control processes.

Engineering companies may still need formal revision numbers, approvals, release procedures and records for regulatory or contractual reasons.

Branching is a tool for managing changes.

It isn't a replacement for your company's QA system.

Are merge conflicts dangerous?

A conflict itself isn't necessarily dangerous.

An unnoticed conflict can be.

That's why I prefer a system that makes the conflict visible.

If two people have made contradictory changes, stopping and asking for a decision is safer than silently overwriting someone's work.

Does a merge conflict mean the software failed?

Not necessarily.

In many cases, a conflict means the software successfully detected something that would otherwise have been hidden.

Think about it this way:

No conflict detection: one change may silently overwrite another.

Conflict detection: the system says two people made different decisions and asks someone to choose.

The second outcome is usually much safer.

What if the two people changed different parts of the drawing?

Those changes should generally be able to merge without requiring manual conflict resolution.

That's one of the main advantages of entity-level comparison.

The system doesn't need to treat the entire drawing as one indivisible file.

What if both people changed the same polyline?

This is where things become more complicated.

A system could attempt to combine individual vertex changes, but that doesn't necessarily produce meaningful engineering geometry.

BranchCAD currently takes the more conservative approach at the entity level: if the same entity has conflicting changes, the user decides which result should be retained.

That is a limitation, but I think it's a better limitation than pretending every geometric conflict can be intelligently blended.

The uncomfortable truth about collaborative CAD

There is a temptation in software to present every problem as something that can be automated.

I don't think CAD should work that way.

Some decisions genuinely belong to the engineer.

If two engineers make different decisions about the same piece of geometry, the answer isn't necessarily hidden somewhere in the coordinates.

Sometimes you simply need to ask:

Which design decision is correct?

The job of the software is to make that question easy to answer.

It should tell you what changed.

It should show you where the conflict is.

It should preserve the history.

And it should make sure neither person's work disappears while you're deciding.

The software handles the mechanics.

The engineer handles the judgment.

The real reason to use branching in 2D CAD

The biggest benefit of branching isn't that you now have a clever way to resolve conflicts.

It's that you can stop being afraid of them.

When people know that a conflict will be detected rather than silently overwriting their work, they can work more independently.

That's the real change.

Instead of organizing the team around the limitations of the CAD file, you organize the CAD workflow around the way the team actually works.

For a small team, that might save a few emails.

For a larger team, it can change how work is divided.

And for a growing engineering company, it can provide something that traditional CAD file workflows often struggle with:

a clear history of how the drawing evolved.

From files to changes

I think this is the bigger shift.

For decades, CAD has largely been organized around files.

You create a file.

You copy it.

You rename it.

You send it.

Someone edits it.

You save another copy.

The result is often a folder full of drawings that technically contain history, but only if somebody is very good at reconstructing it.

Version-controlled CAD changes the unit of thinking.

The question becomes:

What changed?

Then:

Who changed it?

Then:

Was it reviewed?

Then:

Was it approved?

Then:

How did it become part of the main drawing?

That is a much more useful history than a list of filenames.

Try a conflict yourself

You don't have to redesign your entire workflow to understand whether this approach is useful.

Take a small 2D drawing.

Create a branch.

Change one entity.

Have someone else change the same entity on the main drawing.

Then try to merge.

Watch what happens.

A five-minute experiment can tell you much more than a feature list.

If your current workflow depends on people constantly asking:

"Are you finished with that drawing yet?"

then the bigger question may not be whether your team needs faster CAD.

It may be whether your CAD workflow needs better version control.

Branching, merging and advanced visual diff are available with the BranchCAD Pro plan. See the pricing page for the current plan details.

Or open BranchCAD in your browser and try the workflow with a real drawing.

The goal isn't to eliminate every conflict.

It's to make it safe for people to work independently—and obvious when they need to make a decision together.