Why engineers want Git
Walk into any software team and you'll see the same pattern: every engineer working on the same codebase, all the changes tracked, the full history available to anyone who needs it, and an automatic way to merge work from parallel branches. It works because the problem is solved.
Walk into an engineering team and you'll see something older. Folder trees full of files named Bracket_v3_FINAL_revised_v2. Slack arguments about which iteration is actually current. Overwrites that disappear silently because two people edited the same file at the same time. And no history to show an auditor except your notes and memory.
Every engineer who works on a CAD model wishes they had what software teams have. They wish they could branch a design variant without touching the main work. They wish they could see exactly what changed and why. They wish the work didn't vanish when two edits collided. Git solves all of that for code. The question is: why doesn't it work for CAD.
The binary file problem
Git was built for text files. A text file is a list of lines, and Git tracks changes line by line. When two edits touch different lines, Git can weave them together automatically. When they touch the same lines, Git flags a conflict and asks you to decide. The whole system is elegant because it understands the structure of the data: lines are atomic.
A STEP file or a SolidWorks part is not a list of lines. It's a binary blob. The geometry, the features, the parameters, the metadata are all packed into bytes in ways that only the CAD software understands. If you open it in a text editor, you see gibberish. If you flip one feature in the model, the entire byte sequence can scramble. Git, looking at it as pure binary, sees two completely different files with no line-based way to find what actually changed.
This is why plain Git fails for CAD. You can commit a STEP file without any problem, but the moment two people edit it in parallel, you get a binary conflict. Git can't merge it. It can't even show you what changed. You're left with two complete copies of the file and no automated way to decide which one wins. You have to choose by hand, which means understanding both edits well enough to reconstruct the intent. That burden falls entirely on the engineer, every time.
So engineering teams give up on Git and reach for PDM systems instead. Those systems understand CAD files and handle the binary problem correctly. They just come with another set of costs: central servers, licenses, administration, check-out ceremonies, and UIs that feel designed for librarians instead of engineers. Teams often keep a shared drive on the side for the "too small to justify the overhead" work. And teams that can't afford the PDM system have nothing but the shared drive and its _FINAL_revised folder.
Git LFS: storing binaries without Git's overhead
Git LFS is a companion to Git that solves this specific problem. The idea is simple: instead of storing large binary files inside the Git repository, Git LFS stores them separately and keeps only a small pointer file in Git. The pointer is text, and text files work fine with Git's merge logic. When you commit, Git LFS automatically detects recognized file types (.step, .iges, .sldprt, .sldasm, .stl) and routes them to the LFS storage instead of the Git database. You pull, work, edit, and push the same way you always do. Git LFS handles the rest invisibly.
This solves the technical constraint. You can now have parallel edits to CAD files without Git's merge system choking. The binaries are versioned, they're stored efficiently, and they travel with the repository. The history is preserved. And the workflow feels like normal Git because it is.
But there's still a gap. Git LFS is Git under the hood, which means it assumes you already know Git, you already understand remotes and merge strategies and LFS configuration. For a software team, that's fine. For an engineering team with maybe one person who's touched Git before, Git plus Git LFS still has a lot of friction.
How OpenVault closes the gap
OpenVault is version control built specifically for engineering data. It's Git and Git LFS underneath (the same systems software teams already trust), wrapped in a workflow that understands CAD files, BOMs, drawings, and simulation data instead of code.
Here's what that means in practice:
You initialize a repository with a single command. OpenVault sets up Git and Git LFS for you, automatically configures which file types go through LFS, and presents a CLI that mirrors Git's commands so anyone who knows Git feels at home. For everyone else, the commands are obvious. Commit. Branch. Merge. Diff. No remote configuration, no merge strategy decisions, no .gitattributes files to maintain.
When you commit, you write a message explaining the change, just like with code. That message becomes part of the audit trail. When you branch to explore a design variant, your edits stay in that branch until you're satisfied. When you're done, you merge, and the main design moves forward. If someone else edited the same file while you were working, OpenVault flags the conflict clearly and shows you both versions, because automatic merging of 3D geometry would corrupt the work without telling you. That's the honest choice: trust the human who understands the design intent more than any algorithm.
Large binary files work automatically. You don't configure LFS for each file type. You don't worry about whether a .sldasm assembly file is too big or whether it'll break the repository. OpenVault recognizes engineering formats and just handles them. You work. It remembers. You sync. Everyone gets the change.
The workflow changes
The real payoff is the rhythm the technology creates.
You start your day by syncing, pulling down whatever changed overnight. The history is right there: which models moved, who touched them, when, and what they said about the change. No Slack thread asking "is the new bracket in yet?" The answer is in the version history.
When you start a design change, you branch. You have a private space to iterate, make mistakes, fix them, and refine. The main design stays stable. Your teammates don't see the work-in-progress models, the failed experiments, the three iterations before you got it right.
When you're satisfied, you commit as one unit. The model, the drawing, the BOM, the simulation results that depend on that model, all together in one change. Then you merge. Anyone syncing after that gets the whole coherent revision at once. The pieces that belong together travel together. The downstream outputs never get out of sync with the geometry they depend on.
The audit trail is free
In regulated industries, you need to answer "what changed, when, who did it, and why" for every part of the design. Teams without good version control reconstruct this from emails and notes right before the audit. Teams with PDM systems often dread the work it takes to pull a clean history out of the vault.
With CAD version control the audit trail is a side effect of doing the work. Every commit has an author, a timestamp, a message, and the actual changes. When someone asks for the design history, it's already there. The same discipline that keeps you from losing work also keeps you ready for the audit conversation.
You can start right now
OpenVault is open source under the MIT license. Install it with a single pip command and initialize a repository. The CLI is free for local and command-line use, with unlimited files and unlimited history.
The core solves the problem: version control for engineering data, no server to run, no licenses to negotiate, no seats to count. Offline workflows, branching, merging, full history. That's the offer.
Why this matters
Your CAD files don't have to live in a folder tree named like a software release. You can have the same confidence software teams have had for two decades: every change tracked, every edit remembered, the history always available, the branches protecting your main design while you explore. No PDM deployment required. No seats. No licensing.
You just need version control that understands your data and stays out of your way.