What Is Engineering Version Control?

Saving vs. Versioning: The Crucial Difference

Every engineer has seen this folder structure:

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

There is a fundamental difference between saving a file and versioning it.

When you save a file, you overwrite the past. The version before your change is gone. If you made a mistake, or if someone else started editing the old version without knowing you'd already saved a new one, their work vanishes without trace. Saving is destructive.

Versioning keeps every state of the file intact. Every change becomes a permanent record: what changed, who changed it, when, and why they changed it. You can move forward confidently because the past is always available. If you need to see what the design looked like three weeks ago, you can. If you need to understand why a particular choice was made, the message attached to that change explains it. Versioning is cumulative.

On a shared drive with hundreds of files being edited by multiple people, the difference between saving and versioning costs you lost work, unclear histories, and audits that turn into forensic archaeology.

What Engineering Version Control Actually Does

Version control for engineering teams serves five core purposes.

1. Prevents Lost Work

When two engineers edit the same file at the same time on a shared drive, one person's changes are silently overwritten. Version control detects this collision and prevents the silent loss. Both edits are preserved, and the team is alerted that they need to reconcile the changes deliberately.

2. Keeps a Full History

Every change becomes a permanent commit, stored with its author, timestamp, and message. You can step backward through time to see the state of any file at any point in the past. You can ask questions like: What did the bracket design look like before we added the reinforcing rib? Who made that change? What was their reasoning? The answers are all there in the commit history.

3. Enables Branching for Parallel Work

When you need to explore a design direction without risking the current working design, you create a branch. A branch is a private copy of the entire project where you can make changes, experiment, iterate, and fail freely. The main design stays untouched and stable. When your branch is ready, you merge it back, bringing all your coherent changes in at once. Multiple engineers can work on different branches simultaneously without interfering with each other.

4. Provides Diffs: The Ability to See What Changed

A diff is a comparison between two versions of a file showing exactly what is different. For text files, diffs are line-by-line. For engineering files, diffs show which parts moved, which constraints changed, which drawings were regenerated. Diffs make it fast to understand what a particular change contained, without having to open both revisions in CAD and squint at them side by side.

5. Creates an Audit Trail

In regulated industries such as aerospace, medical devices, and automotive, you are legally required to be able to answer: What changed? When? By whom? And why? Version control builds this audit trail automatically as a byproduct of doing the work. Every commit carries its author, timestamp, and rationale. When an auditor asks for the design history, you don't piece it together from email and memory. You hand over the version control log, which is exact and complete.

Why Binary Files Make Version Control Hard

Version control for software is straightforward because source code is text. A change is a line added, removed, or modified. Two edits to different lines can often be combined automatically. Git, Subversion, and other text-based systems do this well.

Engineering files are almost never text. A SolidWorks part is a dense binary blob with geometry, features, parameters, and metadata packed into a single file. A STEP file is compressed geometry data. A board design is a binary representation of traces, nets, and components. When you flip one feature in your CAD model, the bytes in the file scramble in ways that are meaningless to a text-based tool.

This is why engineering teams could not simply adopt Git. Git alone cannot version binary CAD files faithfully. The bytes change in opaque ways, making history unclear and merging impossible.

Engineering version control solves this by treating binary files differently. Instead of trying to merge two people's edits to the same STEP file automatically (which is an unsolved problem in 3D geometry), version control systems flag the conflict and ask a human to resolve it. The human has the CAD knowledge to understand design intent. The machine does not. This approach is honest: it acknowledges what it cannot do and lets the expert make the decision.

Large binary files present a second problem: size. A single SolidWorks assembly can be 500 MB or larger. If you store every version as a complete copy, your repository becomes huge and slow. Git LFS (Large File Storage) solves this by storing only the differences and managing the large files separately from the repository history. CAD files are routed through LFS automatically, so you get full version history without the storage bloat.

Commits, Branches, and Diffs: What Each One Gives You

Commits are the fundamental unit of version control. When you are satisfied with a set of changes, you commit them. A commit is a snapshot of the entire project at that moment, tagged with your name, the current date and time, and a message explaining what you changed and why. Every commit gets a unique identifier. The full history of the project is the sequence of commits.

Commits solve the "which file is final?" problem. The answer is always: "the one in the latest commit on the main branch." There is no ambiguity, no version confusion.

Branches let you work in parallel without conflict. When you start a substantial piece of work, you create a branch, which is a private copy of the project where you make your changes. Commits to your branch do not affect the main project or anyone else's branches. You can make as many commits as you want, fail, experiment, and refine. When the work is done and reviewed, you merge your branch back into main. Everyone who syncs after that gets your changes.

Branches are crucial for teams because they prevent the "one person edits while another is still working" collision. Each engineer has a clear space to work. The main branch is always in a known state. Reviewed and approved changes come in as coherent units.

Diffs answer the question: what exactly changed in this revision? A diff shows the before and after of specific changes. For text, diffs are lines. For CAD files, diffs might show "part moved 5 mm in X direction" or "drawing was regenerated" or "BOM entry count went from 47 to 52." Diffs are how you do a quick review without opening the CAD tool. They are also how you understand the intent of a historical change without having to reconstruct it from context.