Git for Engineering Data

The problem every engineering team knows

Open any shared drive and you'll find the same pattern:

Bracket_v2.step
Bracket_v3.step
Bracket_v3_FINAL.step
Bracket_v3_FINAL_revised.step
Bracket_v3_FINAL_revised_JK.step

There's a difference between saving a file and versioning it. Saving overwrites the past. Versioning keeps every change, who made it, when, and why. It lets you move forward without losing what came before.

Software teams solved this with Git. Engineering teams have tools like SolidWorks PDM, Windchill, and Teamcenter, but they're built on the enterprise-software model: central servers, per-seat licenses, network dependencies, and a check-out ceremony that turns a quick edit into a formal process. Teams with PDM systems still often keep a shared drive on the side. Teams without them have nothing but folder hierarchies and naming conventions.

The real barrier is technical. Git was built for text files made of lines where changes can often be merged automatically. CAD files are binary blobs; flip one feature and the bytes scramble beyond what line-based tools can read. Engineering was left to the PDM vendors, who solved the binary problem but reintroduced all the complexity Git had eliminated.

OpenVault puts Git and Git LFS underneath, wrapped in a workflow tuned for how engineers actually work with CAD files.

How OpenVault works

Git-style workflow for CAD. Every change becomes a commit with an author, timestamp, and message. You can branch to explore a design variant, diff two revisions to see what changed, and do it all offline then sync when connected. The commands mirror Git on purpose so anyone who already knows it feels at home. For everyone else, OpenVault hides the parts that have nothing to do with your job: LFS configuration, remotes, merge strategies.

Honest conflict handling. OpenVault does not try to automatically merge two people's edits to the same STEP file. Automatic merging of 3D geometry is unsolved, and any tool that attempts it will eventually corrupt someone's design. When two branches change the same file, OpenVault flags the conflict and shows both versions for you to resolve by hand. A version control system earns trust by behaving consistently and predictably.

Multi-file coherence. A real design revision touches the model, the drawing, the BOM, and the simulation deck. OpenVault tracks them as one commit so the relationship between a model and its downstream outputs never breaks.

Large binaries without friction. SolidWorks assemblies can be hundreds of megabytes. OpenVault routes recognized engineering files through Git LFS automatically (.step, .iges, .sldprt, .sldasm, .stl, and more) with no tracking rules for you to configure.

Works with your CAD tools. OpenVault sits underneath the files you already produce, in whatever tool you already use. SolidWorks, Fusion, CATIA, NX, KiCad, Altium, FreeCAD. OpenVault tracks files faithfully regardless of what created them.

A day with OpenVault

You start the morning by syncing, pulling down what teammates committed overnight. Before you touch anything, you can see exactly what moved: which models changed, who changed them, and why they changed. There's no archaeology, no Slack thread asking "is the bracket revision in yet?"

When you start a real change, you branch. Now you have a private space to iterate. You can make the model wrong three times, refine it, try a different approach, and none of that churn touches the main design. The main design stays stable while you explore.

When the rework is done, you commit it as one unit: the updated part, the regenerated drawing, the revised BOM line, the re-run simulation. Then you merge it back. Anyone who syncs after that gets the whole coherent change at once. The pieces that belong together travel together.

If someone else happened to edit the same file while you were working, OpenVault stops and tells you. It shows you both versions and lets the person who actually understands the design intent decide. That review step keeps the design intent intact and the history trustworthy.

Why this matters: the audit trail

In regulated industries. aerospace, medical devices, automotive. you are expected to answer "what changed, when, by whom, and why" for any part of a design. Teams without good version control reconstruct this after the fact from email and memory, usually the week before an audit. Even teams with a PDM system often dread it because pulling a clean history out of the vault is its own project.

With OpenVault the audit trail is a byproduct of doing the work. Every revision already carries its author, timestamp, and rationale because that's what a commit is. When someone asks how the design reached its current state, you don't assemble an answer. You already have one. The discipline that keeps your team from losing work also keeps you ready for the conversation you eventually will have.

Get started

OpenVault is free and open source under the MIT license and installs from PyPI:

pip install openvault
openvault init

The CLI covers local and command-line use with unlimited files and unlimited history. When a team wants to collaborate over the web, Tool Crib Cloud adds a 3D-preview web UI, role-based permissions, and hosted cloud repositories with managed storage.