Why binary files are different
Version control tools were designed around text. In a text file, a change is a set of added, removed or altered lines. The tool can display that change clearly, and if two people edit different parts of the file, it can usually combine their edits automatically.
Binary files, a category that includes most CAD models, assemblies, drawings saved in proprietary formats, images, compiled programs, many spreadsheets and word-processor files, do not work this way. Their contents are not organised in lines a human can read. Three problems follow.
- No meaningful comparison. The tool can tell you that a file changed, but not what changed inside it. A one-hole difference in a model is invisible in the history.
- No automatic merging. If two people edit the same file on different branches, the tool cannot combine the edits. One version has to win, or someone has to redo the other person’s work by hand.
- Storage growth. Small edits can rewrite large parts of the file, so each saved version may take nearly the full file size. A history of many versions of a big assembly can become heavy.
Nothing here makes it impossible to version these files, but it does mean the habits that work for source code need adjusting.
What actually goes wrong
The most common failure is the overwritten edit. Two people open the same model, make different changes, and save. Whoever saves last wins, and the other change is lost, often without anyone noticing until later. With text files, the tool would have flagged a conflict. With binary files, the loss is usually silent unless the team has a process to prevent it.
The second common failure is ambiguity: files named bracket_v3.step, bracket_v3_new.step and bracket_final.step sit in a shared folder and nobody can say which is current or what differs. That is the very problem version control was meant to solve.
A third problem is that many design files depend on others. An assembly refers to its parts, and a drawing refers to a model. Saving a new version of one part without keeping the matching versions of the others can leave a project that does not open correctly or that describes a mixture of states.
General approaches
There is no single answer, and the right one depends on file sizes, team size, the design software and your organisation’s rules. These are the main options.
Exclusive editing, or locking
Only one person edits a given file at a time. The person who wants to edit takes a lock, others can open the file read-only, and the lock is released when the changes are saved. This avoids the unmergeable-edit problem altogether by preventing it. The cost is waiting: if someone holds a lock and goes on holiday, others are blocked. Teams need a simple way to see who holds what and to release locks when necessary.
Some version control systems and file-hosting tools support locking directly. Git does not lock by default, although extensions and hosting services add it for large files.
Large-file extensions
Plain Git stores every version of every file in each copy of the repository, which gets unwieldy with large binaries. Git LFS is a long-established extension that stores large files separately and keeps only small pointers in the main repository. Other approaches work similarly. These help with size and often with locking, but they do not make the files mergeable or comparable.
Centralised systems
Some older centralised systems handle large binary files and exclusive checkout more comfortably than Git does, because a single server holds the files and manages access. Some teams that work mainly with large design files prefer them for that reason.
Product data management
Many CAD packages are used alongside a product data management (PDM) or product lifecycle management system. These track revisions, release states, relationships between parts and assemblies, and who approved what, and they usually integrate with the design software. For teams building physical products under formal processes, such a system is often the better fit than a general-purpose tool. Which systems are available, and how they work, depends on the vendor, so evaluate them against your own needs. The wider context is the product lifecycle that the design belongs to.
Disciplined naming and folders
Where a team is small and tools are limited, a clear convention can go a long way:
- Put the revision in the file name or title block in a consistent format.
- Keep a single folder for current files and another for released or archived ones.
- Never edit a released file; save a new revision instead.
- Keep a short log recording who changed what and why.
This is manual and depends on discipline, but it is far better than guessing.
Store text where you can
One practical strategy is to keep as much information as possible in a form that works well with version control and to treat the binary file as just one artefact.
- Keep source parameters, bills of materials, configuration and notes in text or CSV files, which compare and merge cleanly.
- Where your tool offers text-based export formats, consider whether they are suitable for archiving. Neutral formats can help with long-term access, though they may lose some design information such as feature history, so check what you lose before relying on them.
- Keep generated outputs, such as exported PDFs or meshes, in a separate release area rather than mixing them with sources.
- Record decisions in short written notes, since the file history cannot explain the reasoning. Design decision records are well suited to this.
Practical habits
- Decide up front which files belong in version control and which are generated, and exclude temporary and backup files with an ignore list.
- Name the commit or revision clearly and say why the file changed, as with any other commit message.
- Save new revisions at meaningful points rather than after every small edit.
- Test that a fresh copy of the repository opens correctly, including all referenced parts.
- Back up the repository itself regularly. Version control is not a backup, and a single drive failure can lose all revisions.
- Review changes visually where possible, since the tool cannot. Screenshots, markups or the CAD package’s own comparison features can help, along with design reviews.
For design work that affects safety, compliance or contracts, there are often formal rules about revision control and approval. Those differ by country and industry, so follow the procedures and standards that apply to your organisation.