CAD Version Control Explained

Why CAD breaks plain Git

Git was built for source code. A software file is a text file made of lines, and Git's power comes from understanding changes at the line level. When two developers edit the same file, Git can often merge the changes automatically by checking which lines changed where and reassembling them into a coherent result.

CAD files are different. Open SolidWorks, change a hole diameter by 0.001 inches, save, and the entire binary blob scrambles. Git sees a file that has changed completely, but it has no way to parse the geometry or understand that you only moved one feature. The same happens with STEP files, IGES, assembly formats, and any other 3D interchange file: the changes are meaningful to the software that understands the format, but they look like random bytes to Git.

This binary problem is why CAD was historically left to specialized tools. SolidWorks PDM, Windchill, Teamcenter, and Vault all solve it by storing files in a central database where merging logic is replaced by a check-out ceremony. You lock the file, edit it, and check it back in. No merge conflicts because only one person can edit at a time. For large organizations with the infrastructure to support a central server, this approach works well. Smaller teams often find the overhead burdensome compared to what Git brought to software teams.

How Git LFS fits in

Git LFS (Large File Storage) decouples Git's version control from Git's storage layer. With plain Git, the repository contains the full history of every version of every file you've ever committed. For large binary files, the history balloons fast. A 200 MB assembly saved ten times is two gigabytes in your repository, even if you only care about the most recent version.

Git LFS intercepts certain file types before they go into the repository. Instead of storing the full binary, it stores a pointer: a few lines of metadata that name the file, its size, and a hash. The actual binary lives in a separate LFS store, either on a local drive or on a remote server. When you check out a file, Git LFS downloads the binary from the store. When you push, it uploads new versions. The .git directory stays small by tracking pointers to the files instead of the files themselves.

For CAD files, this means:

• Faster clones and pulls. You are not downloading the entire history of massive assemblies, only the versions you need.
• Easier offline work. Lightweight checkouts mean you can work disconnected and sync when connected.
• No accidental bloat. Someone cannot accidentally commit a hundred gigabytes and break the repository for everyone.
• Version history that behaves predictably. You have a record of every revision that was committed, who committed it, and when.

Git LFS does not solve the merge problem. It solves the storage problem. If two branches modify the same binary CAD file, Git LFS will still flag a conflict. The conflict is genuine and requires a human decision. But at least the repository itself doesn't explode and the history remains trustworthy.

A good CAD version control workflow

A CAD version control workflow does four things well: it commits complete, coherent changes. it handles conflicts honestly, it preserves the relationship between a model and its downstream outputs, and it makes history auditable.

Commit complete changes

In software, a commit is often a single code change. In CAD, a change usually touches multiple files: the 3D model, the 2D drawing, the part list, maybe a tolerance stack-up or simulation input deck. These files are interdependent. A commit should capture the whole update as one unit so the pieces that belong together travel together.

When a teammate syncs after your commit, they get a fully consistent state. The part, the drawing, and the BOM line up. There's no intermediate state where the model is new but the drawing is stale, or vice versa.

Handle conflicts by hand

When two branches modify the same CAD file, version control systems have to make a choice: attempt automatic merge or flag a conflict and ask a human. Any tool that auto-merges binary 3D geometry is either not reading the geometry (in which case the merge is blind and could break something) or attempting something research communities haven't solved yet.

A mature version control tool flags the conflict and shows both versions. The person who actually understands the design intent looks at both and makes the decision: keep mine, keep theirs, or combine them. This takes more effort in the moment, but it keeps the design history trustworthy and honest. You know that every design in the history was explicitly reviewed and decided by someone who understood it, rather than merged by an algorithm that guessed.

Keep downstream outputs in sync

A design is not just the 3D model. It's the model plus the drawings, BOMs, simulation results, and material certifications that flow from the model. If the model changes but the drawing doesn't, the discrepancy will be discovered in the shop or during audit, not before release.

Good CAD workflows commit the model and its drawings together. When you update a part, you regenerate the drawing at the same time and commit both in one go. Some teams use rules: "if you touch a model file, you must touch its drawing file." Others use tooling to regenerate drawings automatically and then commit everything as one set. The key is that the relationship between the model and its outputs is maintained in the version history, so any past revision stays coherent.

Make history auditable

In regulated industries, you are expected to answer: what changed, when, by whom, and why. Teams without version control reconstruct this from memory and email, usually under pressure. Teams with Git (or a PDM system) have an audit trail as a byproduct of doing the work.

Each commit carries an author, timestamp, and a message that explains why the change was needed. Over time, the commit log becomes the design history. You can walk a design forward from inception to release and understand the decision at each step. When an auditor asks "why did you choose that material," you point to the commit that introduced it and its message explains the reasoning.

This kind of traceability requires discipline: commit messages have to be clear, the granularity of commits has to be intentional (don't cram ten unrelated changes into one commit), and the habit of committing before merging into a release branch has to be standard. But for teams in aerospace, medical, automotive, or other regulated spaces, the difference between reconstruction and a clean audit trail is enormous.

Getting started with Git LFS and CAD

If you are starting fresh, the setup is straightforward:

1. Initialize a Git repository: git init in your project folder.
2. Install Git LFS: most package managers have it (brew install git-lfs on macOS, apt install git-lfs on Ubuntu, or download from the Git LFS site).
3. Set up tracking rules: tell Git LFS which files are large binaries. A common pattern covers CAD files:

git lfs track "*.step"
git lfs track "*.stp"
git lfs track "*.iges"
git lfs track "*.igs"
git lfs track "*.sldprt"
git lfs track "*.sldasm"
git lfs track "*.stl"
git lfs track "*.pdf"

4. Commit the .gitattributes file (Git LFS creates this) so teammates get the same tracking rules.
5. Start committing. CAD tools like SolidWorks, Fusion, CATIA, NX, and FreeCAD save files naturally; just git add the results and commit with a clear message about what changed.

Tools like OpenVault wrap this workflow and automate the Git LFS configuration so you focus on the design work, not the plumbing. OpenVault ships with pre-configured tracking for common CAD formats, so you install it with pip install openvault and start using it without manually setting up LFS files.

Workflow recommendations

• Branch for variants. If you are exploring a design change, create a branch instead of editing main. This keeps the main design stable while you iterate. Once you are confident, merge the branch back.
• Write clear commit messages. Include the why, not just the what. Instead of "Update bracket," write "Update bracket hole diameter to fit new fastener per new spec revision." Future you (and auditors) will thank present you.
• Sync often. Small pulls and pushes are faster and create less friction than big syncs. Check in work every couple hours if you are in an active project.
• One commit per logical change. If you change the model and update its drawing, do it in one commit. If you fix a tolerance issue on a different part, that is a separate commit. Clear boundaries make history readable.

Version control across multiple CAD tools

One of Git's and Git LFS's advantages is tool agnosticism. You can manage files from SolidWorks, Fusion, CATIA, NX, KiCad, Altium, and FreeCAD in the same repository. The version control does not care what created the file, only that the bytes are tracked and the history is preserved.

This matters for mixed shops. If your mechanical team uses SolidWorks but your electrical team uses KiCad, you can version everything in one repository. If you are collaborating with a partner who uses a different CAD tool, you can exchange STEP files that both your systems read. Git LFS handles the binaries the same way regardless of tool. The STEP file is just another binary file with a clear format that works everywhere.

For teams migrating from a PDM system to Git-based version control, this flexibility means you are not locked into a single vendor anymore. You can switch CAD tools, choose your own storage backend, and keep the same version control discipline.