Software version control assumes two people can edit the same file and a tool can merge the result. CAD assumes they can't — and builds locking, not merging, as the answer.
Engineers who've used Git for code, or watched a software team use it, sometimes ask why CAD teams don't just put their assembly files in a Git repository and get the same branching, merging, and full history for free. The honest answer isn't organizational inertia — it's a real technical limitation. Git's merge algorithm works because source code is line-based text: two people's changes to different lines of the same file can usually be combined automatically, and even a genuine conflict shows up as readable, resolvable text. A CAD file — a binary tree of geometric features, references, and metadata — has no line-based structure for a diff/merge algorithm to reason about, so two people's simultaneous edits to the same part file can't be reliably combined at all. PDM systems solve the same underlying problem — preventing two people from destroying each other's work — with a fundamentally different mechanism: an exclusive lock, not a merge.
Git (and similar distributed version control) is an optimistic concurrency system: it assumes conflicts are rare enough, and resolvable enough, that letting everyone edit freely and reconciling differences afterward is more productive than blocking anyone up front. That assumption holds for source code because a merge algorithm can operate on lines of text — if two people touched different lines, the merge is unambiguous and automatic; if they touched the same lines, the conflict shows up as clearly marked, human-readable text a developer resolves by hand. A CAD assembly file has no equivalent structure a generic merge tool can reason about — it's an opaque binary encoding of a feature tree, geometry kernel data, and references to other files, and two independently edited copies of the same part generally can't be reconciled into a single coherent result at all. PDM systems instead use pessimistic locking: checking a file out grants one person exclusive write access and marks it read-only for everyone else, which sidesteps the unsolvable merge problem entirely by making sure the conflicting edit situation never happens in the first place. Checking back in creates a new immutable revision and releases the lock, at which point the next engineer can check out that revision for their own edit.
Git can technically version any file, including binary CAD files — but "versioning" and "merging" are different capabilities, and it's specifically merging that breaks down. Git will happily store two people's conflicting edits to the same part file as two separate commits, but when it comes time to merge those branches, its line-based diff algorithm has no meaningful way to interpret the binary difference between them — the best it can do is flag the whole file as conflicted and force someone to pick one version and manually redo the other person's changes from scratch, which is exactly the outcome PDM check-out locking was designed to prevent from happening at all. Some CAD-aware version-control add-ons and Git LFS (Large File Storage) workflows exist to handle the large binary payload problem more gracefully, and a few CAD-specific PDM/PLM systems have started offering true model-aware merge for certain simple, non-overlapping structural changes — but as a general capability across arbitrary CAD edits, mergeable binary CAD data remains an unsolved problem industry-wide, which is why exclusive check-out locking, not branch-and-merge, is still the dominant concurrency model for CAD data management.
Explains why CAD teams use PDM's exclusive check-out locking instead of Git-style branch-and-merge — not organizational habit, but a real technical limitation: binary CAD files have no line-based structure for a generic merge algorithm to reconcile, so PDM prevents the conflict with a lock instead of resolving it after the fact.
Engineers with software development exposure reasonably ask why mechanical design teams don't get the same distributed, branch-and-merge workflow software teams take for granted. The two domains share the word "version control," which invites the assumption that CAD data management is just an underdeveloped or old-fashioned version of the same idea Git solved for code. In fact, the two problems differ at a structural level: Git's merge capability depends on source code's line-based, human-readable text structure, which CAD's binary geometric feature-tree format simply does not share.
Git implements optimistic concurrency: any number of people can branch and edit a repository simultaneously with no locking, on the assumption that most simultaneous edits touch different parts of a file (or different files) and can be automatically reconciled at merge time by a line-based diff/merge algorithm; genuine overlapping edits are flagged as a merge conflict rendered as readable text markers for a person to resolve by hand.
PDM (Product Data Management) systems implement pessimistic locking instead: checking a file out from the vault grants one user exclusive write access and marks it read-only everywhere else in the system, which prevents a conflicting simultaneous edit from ever being created rather than trying to reconcile one after the fact. Checking the file back in creates a new immutable revision, updates any parent assembly references, and releases the lock so the next person can check it out. This mechanism has nothing to do with the file's internal structure, which is exactly why it works uniformly across binary CAD parts, assemblies, drawings, and any other file type a PDM vault might store — where a merge-based system would need to understand each format's internals to do anything useful with it.
Multi-engineer teams working on the same assembly rely on PDM check-out/check-in specifically to prevent the scenario where two engineers independently edit the same part file and one person's work is silently lost or has to be manually redone — a failure mode common in ad hoc shared-drive CAD workflows without any concurrency control at all. Some engineering organizations do use Git (or similar) successfully alongside CAD, but typically for artifacts that are genuinely text-based and mergeable — configuration files, scripts, generative-design definition files, simulation input decks — rather than for the native binary CAD part and assembly files themselves, which stay under PDM/PLM check-out control.
Git can store any file, but its core design (storing full snapshots and computing diffs) is optimized for text; Git LFS (Large File Storage) is an extension that stores large binaries outside the main repository history and keeps only lightweight pointers in Git itself, addressing the storage-bloat problem but not the underlying merge-ability problem for binary CAD content.
Some support parallel "revision" or "variant" workflows that superficially resemble branching — for example, letting two engineers work on separate proposed changes to the same released part before one is selected — but reconciling those parallel efforts back into one file still generally requires a person to manually pick and rebuild the winning changes, not an automatic structural merge the way Git handles text.
Depending on the PDM system's integration with the CAD software, the file typically opens read-only, or the CAD application blocks save operations back to the vaulted location and forces a "save as" to a separate, unmanaged copy — which then has to be manually reconciled by a person once the original lock is released, since the system has no automatic way to combine the two divergent edits.
Yes — a single popular shared file (a top-level assembly, a common bracket used across many designs) can become a serialization point where engineers queue up waiting for the lock to release, which is a known limitation of pessimistic locking generally. Some PLM systems mitigate this with sub-assembly modularization (splitting large assemblies so fewer engineers need the exact same file) rather than solving the underlying concurrency problem directly.
Try our Engineering Software Studio
More calculators, simulators, and guides for this discipline.
Engineering Software Handbook (Full Access)
✨ Premium ContentA zoomable interactive reader — free preview, then unlock the full set.