Why does Git work so well for software but so poorly for CAD assemblies?

Git was designed around line-based diffing and merging of text files: it can look inside a file, see that only a few lines changed, store just that delta efficiently, and if two people edited different lines it can often merge both sets of changes automatically. A CAD file, whether a SolidWorks part, an Inventor assembly, or a STEP export, is a binary format, so Git cannot see 'inside' it to compute a meaningful diff — from Git's perspective the file either changed or it didn't, and every save stores a complete new binary blob rather than a small delta, which bloats repository size fast on large assemblies. Worse, if two engineers edit the same part file on different branches, Git has no way to merge their binary changes the way it merges two text files; it can only ask a human to pick one version or the other, which typically means someone's edits get silently lost. This is precisely why real engineering teams don't try to force CAD data through Git and instead use PDM systems, which solve the problem with file locking rather than merging.

What's the actual difference between PDM and PLM?

PDM (Product Data Management) is scoped to managing engineering files themselves: CAD models, drawings, and their revisions, who has each file checked out, and the relationships between parts and assemblies. It is essentially the engineering department's file vault and revision history. PLM (Product Lifecycle Management) is a broader superset that manages a product's entire life, from initial requirements and concept, through design (where it typically wraps a PDM system underneath), to manufacturing planning, quality records, service documentation, and eventual end-of-life or obsolescence. Every PLM system needs PDM-like file management to function, but not every team needs full PLM — a 10-person mechanical design shop usually gets everything it needs from PDM alone, while a large multi-department manufacturer coordinating design, quality, and supply chain typically needs full PLM to keep those departments working from the same authoritative data.

How does check-in/check-out file locking actually prevent engineers from overwriting each other's work?

When an engineer opens a CAD file from a PDM vault for editing, the system marks that file as checked out to them specifically, and every other user's local copy becomes read-only for that file until it is checked back in. This is a pessimistic locking model: rather than letting two people edit simultaneously and trying to merge or reconcile the result afterward (which, as with Git, is unreliable for binary CAD data), the system simply prevents the conflict from ever occurring by only allowing one editable copy to exist at a time. When the engineer finishes and checks the file back in, the PDM system creates a new revision, releases the lock, and the file becomes available for the next person to check out. The tradeoff is that a file checked out by someone who is away or has left the company can block others from working — which is why administrators can force an override check-in when genuinely necessary, and why some newer PDM systems are experimenting with more granular, feature-level locking to reduce how often a whole file needs to be locked for a small change.

What is an Engineering Change Order and why does it matter more than just editing the CAD file?

An Engineering Change Order (ECO), sometimes called an Engineering Change Request/Notice depending on the company's process naming, is a formal, tracked record that a specific change to a released part or assembly was proposed, reviewed, approved by the relevant stakeholders (design, manufacturing, quality, sometimes a customer), and implemented, along with why the change was needed and what it affects downstream. This matters far more once a part has been released, meaning it has already been used to build, quote, or ship a physical product, because at that point silently editing the CAD file would leave no record connecting the physical parts already in the field or on the shop floor to the exact design revision they were actually built from. A PDM or PLM system enforces this by locking released revisions from casual editing and requiring a new revision, created through the ECO process, for any further change — which is also what allows manufacturing to always answer the question 'which exact revision of this part is installed in serial number 4471,' a question that becomes critical during a recall, a warranty claim, or a failure investigation.

Design·11 min read·July 7, 2026

🗂️ Version Control & PLM for Engineering Data: Git, PDM, and Product Lifecycle Management Explained

A practical guide to managing engineering data over time: why Git works well for text-based code but poorly for CAD files, how PDM and PLM systems solve file locking and revision control for engineering teams, and how release states and BOMs tie it all together.

By EngineersUniverse Editorial Team

Engineering Editorial & Technical Review Team

Published July 7, 2026

Why Engineering Data Management Is a Different Problem Than Software Version Control

Software developers take for granted that version control just works: branch, edit, commit, merge, done. Mechanical, electrical, and other hardware-adjacent engineers who try to manage CAD files the same way with Git or a shared network drive quickly discover it doesn't. Understanding why requires looking at what actually happens inside these two very different kinds of files.

A source code file is plain text, organized in discrete lines. Version control systems like Git are built around line-based diffing: when a file changes, Git can compare the old and new versions line by line, identify exactly which lines were added, removed, or modified, and store just that small delta rather than a whole new copy of the file. When two developers edit the same file on different branches, Git's merge algorithm can often reconcile both sets of changes automatically, as long as they touched different lines — and when it can't, it clearly flags the specific conflicting lines for a human to resolve by hand.

A CAD file is a binary format — a SolidWorks .sldprt, an Inventor .ipt, or even a neutral STEP export is not organized as readable lines of text but as a proprietary internal structure (geometry kernels, feature trees, metadata) that only the originating application, or a compatible one, can meaningfully interpret. From a generic version control tool's point of view, the file is just an opaque blob of bytes. It cannot diff two versions to show what changed; it can only detect that the file as a whole is different, and it must store a full new copy of that (often large) file every time it changes rather than a small delta, which causes repository size to balloon quickly on any assembly of real complexity. Far more seriously, when two engineers edit the same part on different branches, there is no reliable way to merge their binary changes the way Git merges two text files' non-conflicting lines — the system can only ask a human to pick one version entirely, silently discarding whichever set of edits wasn't chosen. For a single-file script this might be a survivable inconvenience; for a shared assembly with dozens of dependent parts, it is a serious data-integrity risk.

How PDM Solves the Problem: Locking Instead of Merging

Product Data Management (PDM) systems are purpose-built to manage this exact situation, and they solve it with a fundamentally different strategy than Git: instead of allowing simultaneous edits and attempting to merge the results afterward, PDM systems use pessimistic locking (commonly called check-in/check-out) to prevent the conflict from ever happening in the first place.

When an engineer wants to edit a file stored in a PDM vault (the managed, versioned file repository at the center of any PDM system), they check it out. This marks the file as locked to that specific user, and every other team member's copy of that file becomes read-only until it's checked back in — anyone else who tries to open it for editing is told who currently has it locked. The engineer makes their changes locally, and when finished, checks the file back in, which uploads the new version to the vault, creates a new tracked revision, and releases the lock so the next person can check it out. This model trades the flexibility of simultaneous editing for the guarantee that two people's binary CAD edits can never silently overwrite one another, which is the right tradeoff for file types that cannot be reliably auto-merged.

The obvious downside is that a file checked out by someone on vacation, in a meeting, or who has left the company can block everyone else from working on it. PDM systems handle this with administrator-level override permissions to force a check-in when genuinely necessary, and some newer systems are exploring more granular, feature-level locking (locking only the specific feature being edited rather than the entire file) to reduce how often this bottleneck occurs. Beyond locking, a PDM vault also maintains the full revision history of every file, tracks the parent-child relationships between parts and the assemblies that reference them (so the system knows an assembly needs updating when one of its component parts changes), and typically integrates directly into the CAD application itself so check-in/check-out and revision browsing happen without leaving the modeling environment.

PDM vs. PLM: Scope, Not Just Software

PDM and PLM are frequently used interchangeably in casual conversation, but they describe different scopes of the same underlying problem.

PDM is scoped specifically to engineering file and revision management: CAD models, drawings, associated documents, who has what checked out, and the structural relationships between parts and assemblies. It is, in effect, the engineering department's authoritative, access-controlled file vault with a complete history attached.

PLM (Product Lifecycle Management) is the broader superset, managing a product's entire life from initial concept and requirements definition, through the design phase (where it typically wraps a PDM system as its engineering-data layer), into manufacturing process planning, supplier and quality records, field service and warranty history, and eventual obsolescence or end-of-life planning. A mature PLM deployment connects engineering's CAD data to manufacturing's routing and work instructions, to quality's inspection records, and sometimes to the sales and service organizations' view of what was actually shipped to a given customer — all referencing the same underlying part and revision identifiers rather than each department keeping its own disconnected spreadsheet.

Every PLM system requires PDM-like file management underneath it to function at all, but not every organization needs full PLM. A small mechanical design shop with a handful of engineers usually gets everything it actually needs — reliable file locking, revision history, and release control — from PDM alone (examples include SolidWorks PDM, Autodesk Vault, and PTC Windchill's lighter-weight PDM tier). A larger manufacturer that must coordinate design, manufacturing, quality, and supply-chain teams around the same product data typically needs full PLM (examples include Siemens Teamcenter and the full Windchill platform) to keep those departments working from a single, consistent source of truth rather than files and spreadsheets emailed between departments and inevitably drifting out of sync.

Release States and the Engineering Change Order Process

A part or assembly's journey through a PDM or PLM system typically follows a defined sequence of release states, commonly something like: Work in Progress (actively being designed, freely editable by its owner), In Review (submitted for design review or approval, typically read-only pending sign-off), Released (approved and available for use in manufacturing, purchasing, or downstream assemblies), and Obsolete (superseded or retired from active use). This state machine is not just bookkeeping — most systems enforce it, for instance preventing a released part from being casually re-edited, or preventing an assembly from being released if it still references a component that is only in work-in-progress state.

Once a part reaches Released status, meaning it has been used to quote, purchase, manufacture, or ship something, editing its CAD file directly would break the traceability link between the physical parts already built or in the field and the specific design revision they were actually built from. This is exactly the problem an Engineering Change Order (ECO) — sometimes split into a separate Engineering Change Request that gets reviewed and approved before becoming a Notice — is designed to solve. An ECO is a formal, tracked record that a specific change to a released item was proposed, why it was needed, who reviewed and approved it (often including design, manufacturing, and quality stakeholders, and sometimes a customer for regulated or contracted work), and what the change actually affects downstream, such as tooling, inventory of the old revision, or in-field units. Implementing the change then creates a new formal revision (commonly incrementing a letter or number, such as Rev A to Rev B) rather than silently overwriting the released one. This is what lets an organization answer, with confidence, exactly which design revision of a part is installed in a specific serial-numbered unit — a question that becomes critical during a product recall, a warranty investigation, or a root-cause failure analysis, none of which are answerable if changes to released designs aren't formally tracked.

How This Connects to the Bill of Materials

A Bill of Materials (BOM) — the structured list of every part, subassembly, quantity, and reference designator that makes up a product — is generated from, and tightly linked to, the same revision-controlled part data managed in PDM/PLM. Because each part and assembly carries a specific revision, a BOM pulled from a well-managed PDM/PLM system reflects an exact, unambiguous configuration of the product as of a specific point in time, rather than an approximate list assembled by hand from whatever files happened to be on someone's drive. When an ECO changes a part's revision, the systems that consume that BOM — manufacturing's work orders, purchasing's procurement records, and quality's inspection criteria — can all be updated from the same authoritative source rather than requiring someone to manually propagate the change across multiple disconnected documents, which is one of the most error-prone manual processes a hardware engineering organization can have.

Practical Takeaways

For an individual engineer or a very small team working mostly with parametric CAD files, plain Git (or a generic cloud file sync tool) is not the right tool for managing that CAD data day-to-day — it will silently lose work the first time two people edit the same assembly component in parallel, and its version history will bloat rapidly on binary files it cannot meaningfully diff. A dedicated PDM system, even a lightweight one, solves the actual problem (preventing simultaneous binary edits, tracking real revision history, controlling release states) that generic version control tools were never designed for. Git remains an excellent choice for the actual source code, scripts, and configuration files that frequently live alongside engineering projects — CAM post-processors, PLC or firmware source, automation scripts (see the companion article on CAD scripting and automation on this site) — since those genuinely are text files that benefit from real diffing and merging. The two tools are not competitors; they are suited to different kinds of files, and a well-run engineering organization typically uses both, each where it actually fits.

Topics covered

engineering data managementPDM vs PLMCAD version controlGit for engineersproduct lifecycle managementfile check-in check-outengineering change orderbill of materials managementrevision control CAD filesPDM vaultTeamcenter Windchill comparisonbinary file version controlCAD file lockingrelease state workflow

🛠️ Related Free Tools

Put this knowledge to work on your iPhone

Browse our full catalog of professional iOS apps — from electrical code tools to AI builders.

Browse All 95+ Apps