CAD Version Control for Engineering Teams — Git, PDM, and File Naming Systems Compared

Engineering version control for CAD is harder than it looks. A 50 MB SolidWorks assembly changes at the binary level every time you open and save it — even if you moved nothing. Most version control advice comes from software engineers working with text files, and it doesn’t translate cleanly.

This guide covers the actual decision: whether to use Git + LFS, a dedicated PDM system, or folder-based naming — what each costs in setup and maintenance, and where each breaks down. Updated June 2026.

Why CAD Version Control Is Different

The binary file problem

SolidWorks .sldprt files are OLE Structured Storage containers. AutoCAD DWG files use Autodesk’s proprietary binary format. Neither can be diffed or merged by any standard VCS tool. When two engineers modify the same file simultaneously, one of them will overwrite the other’s work — there is no merge path.

This forces a fundamental constraint: only one person can work on a file at a time, or you need a system that enforces that rule with locks. Every version control strategy for CAD either accepts this constraint or hides it (badly).

File size math

A typical small-to-mid product might have:

• 300 part files averaging 3 MB each = 900 MB
• 80 assembly files averaging 15 MB each = 1.2 GB
• 150 drawing files averaging 2 MB each = 300 MB

Total: ~2.4 GB of active CAD data. If you’re storing 20 revisions of each file (not unreasonable over a product lifecycle), that’s 48 GB of repository data. Git repositories are not designed for this. PDM systems are.

Dependency chains

SolidWorks assemblies reference part files by absolute or relative path. If you reorganize folders, the references break and assemblies won’t open. This means you can’t rename or move files freely — the version control system needs to track and update references when files are renamed. Git and Subversion do not do this. SolidWorks PDM and Vault do.

Git + LFS for CAD: When It Works, When It Doesn’t

Git is the right answer for teams that are already using it for firmware, software, or documentation, and want to extend it to CAD without buying PDM software.

Setting up Git LFS for SolidWorks

Git LFS stores large files on a separate server (GitHub LFS, Azure DevOps LFS, or self-hosted) and replaces them with lightweight pointer files in the Git repository. Without LFS, a 50 MB .sldasm gets baked into Git’s object store on every commit, and the repository becomes unusable within weeks.

# Install Git LFS (one-time, per machine)
git lfs install

# Track SolidWorks file types
git lfs track "*.sldprt"
git lfs track "*.sldasm"
git lfs track "*.slddrw"
git lfs track "*.sldlfp"

# Track other CAD formats if you mix tools
git lfs track "*.iam"   # Inventor assembly
git lfs track "*.ipt"   # Inventor part
git lfs track "*.dwg"
git lfs track "*.step"
git lfs track "*.stp"

# Commit the .gitattributes file that LFS generates
git add .gitattributes
git commit -m "Configure Git LFS for CAD files"

Always run git lfs track before committing any CAD files. Running it after means your existing files are already in Git’s regular object store — you’ll need to migrate them with git lfs migrate import.

File locking in Git LFS

Without locking, two engineers can both pull the same SolidWorks file, modify it in parallel, and push to the same branch. The second push will fail (non-fast-forward), and you’ll have a conflict you can’t resolve automatically.

Git LFS has a locking mechanism, but it requires server-side support (GitHub, Azure DevOps, and Gitea all support it):

# Mark a file type as lockable
git lfs track --lockable "*.sldprt"
git lfs track --lockable "*.sldasm"

# Lock a file before editing
git lfs lock path/to/Housing.sldprt

# Check what's locked (and by whom)
git lfs locks

# Unlock after committing
git lfs unlock path/to/Housing.sldprt

When a file is locked, Git LFS makes the local copy read-only for everyone else. SolidWorks respects the read-only flag — it will warn you that the file is read-only before you try to make changes. This is the closest you get to PDM-style checkout enforcement in a Git workflow.

Git LFS limitations to plan around

Storage costs scale fast. GitHub charges $5/month per 50 GB of LFS storage. Azure DevOps includes 2 GB LFS free. For a 48 GB CAD repository, expect $50–100/month in LFS storage fees on top of any self-hosting costs.

Bandwidth on every checkout. LFS downloads the full file on each git checkout. On a slow connection or for engineers working from home, pulling a new branch with 500 modified CAD files can take an hour.

No reference path management. If you move Housing.sldprt from /Mechanical/Body/ to /Mechanical/Housing/, Git can track the rename — but SolidWorks doesn’t know about the move. All assemblies that reference that file by path will break the next time someone opens them. You need to manually fix all references in SolidWorks before committing the restructured paths.

Works best for: Small teams (under 8 engineers), teams that already use Git for code, projects where the CAD file count is under 500, and situations where PDM licensing cost ($4,000–8,000 per seat) is prohibitive.

PDM Systems Compared

If your team is SolidWorks-only and has budget for licensing, a PDM system is the right tool. It understands SolidWorks file references, enforces check-out locking at the application level (not the file system), and manages revisions through lifecycle states.

SolidWorks PDM Standard vs Professional

Standard is the entry level. It ships bundled with SolidWorks Professional and Premium subscriptions, so many teams already have it.

Standard includes:

• Local vault with check-in/check-out
• Revision history and revision numbering
• Reference tracking (knows when assembly A references part B)
• Simple workflow states (in-work, pending approval, released)
• Basic search

Professional adds:

• Web client (view and approval without SolidWorks installed)
• Item master for purchased parts (not just CAD files)
• BOM comparison between revisions
• Full scripting API for automation
• Enterprise replication for multi-site teams
• Bi-directional ERP integration (SAP, Oracle, Epicor adapters)

For teams below 20 engineers doing straightforward product development, Standard covers 90% of needs. The upgrade case for Professional is usually one of: multi-site replication, ERP data handoff, or web-based review for non-CAD stakeholders.

Vault vs PDM for Inventor shops

Autodesk Vault and SolidWorks PDM solve the same problems with different integration depth. Vault integrates directly into Inventor’s ribbon — check-out, check-in, and reference resolution happen inside the CAD interface. PDM does the same for SolidWorks.

If you run a mixed shop with both SolidWorks and Inventor, neither integrates cleanly with the other’s PDM. The options are:

1. Use Windchill or Arena (format-agnostic enterprise PLM) — expensive
2. Pick one PDM and accept weaker integration for the secondary tool
3. Use Git + LFS for the secondary tool with manual coordination

Most mixed shops end up picking based on headcount: whichever CAD tool has more seats drives the PDM choice.

File Naming Conventions That Survive Real Projects

Naming conventions break down when projects get old, people leave, or files get copied between projects. The systems that survive are the ones where the naming rules are enforced by software (PDM auto-numbering) or are so simple they can’t be misapplied.

Number-based naming (recommended for PDM shops)

If you have PDM, use auto-generated part numbers and let the PDM description carry the human-readable name:

1001234.sldprt        → "Housing, Motor Mount, 6061-T6 Al"
1001235.sldasm        → "Subassembly, Drive Unit"
1001236.slddrw        → "Housing, Motor Mount — Drawing"

The part number is the identifier. The description in the PDM tells you what it is. This prevents the situation where two engineers independently name parts HousingMounted.sldprt and MountedHousing.sldprt in separate projects and neither is searchable.

Descriptive naming (for teams without PDM)

If you’re using Git or a folder-based system, you need the filename itself to carry enough context:

[ProjectCode]_[Assembly]_[Component]_[Material]_Rev[X].sldprt

Examples:
PRJ24_DriveUnit_MotorMount_6061Al_RevA.sldprt
PRJ24_DriveUnit_MotorMount_6061Al_RevB.sldprt
PRJ24_DriveUnit_GearboxHousing_Cast380_RevA.sldprt

Rules that actually work:

• No spaces — causes problems with command-line tools and some PDM clients
• Prefix with project code — prevents filename collisions when parts are shared
• Material in the name — eliminates the common “which housing?” confusion between steel and aluminum variants
• RevX at the end — sort order in a folder then shows revision progression
• No dates in filenames — use the VCS timestamp for that

What breaks naming conventions:

• Copied files that inherit old names from a template project
• Parts that start as unique and later become shared standard components
• Revision letters that skip (RevA → RevC — where did RevB go?)

The fix for copied templates: rename immediately on project creation, before any modeling starts. Renaming SolidWorks files after modeling means manually repointing references.

Managing references when files are renamed

Every time you rename a SolidWorks part file, any assembly that references it breaks until you update the reference. SolidWorks PDM handles this automatically — it tracks the internal document GUID, not the file path. Git does not.

For Git-based workflows, the safest approach is to finalize naming before the file is referenced by any assembly. After a part is mated into an assembly, treat the filename as immutable unless you’re prepared to open every downstream assembly and fix the reference manually.

Essential Version Control Strategies

Centralized vs. Distributed Approaches

Centralized version control works well for CAD file management because it provides a single source of truth for large binary files. Systems like Perforce or Subversion handle binary files efficiently and provide the locking mechanisms CAD workflows require.

File locking prevents simultaneous edits that could create merge conflicts. When you check out a CAD file for editing, other team members see it as locked and know to coordinate changes with you.

Distributed systems like Git face challenges with large binary files, though Git LFS (Large File Storage) addresses some limitations. The distributed model can work for smaller teams with good coordination practices.

Naming Conventions and File Organization

Consistent naming conventions form the foundation of effective CAD file management. Establish clear rules for part numbers, assembly names, and revision identifiers before starting any project.

Use descriptive names that indicate the component’s function and position in the assembly hierarchy. For example: Housing_Motor_Mount_Rev_C.sldprt clearly identifies the part’s purpose and current revision.

Organize files in logical directory structures that mirror your product breakdown structure. Group related components together and separate different product lines or projects into distinct folders.

Revision Control Methods

Implement a formal revision control system that tracks design changes through defined stages. Use letter-based revisions (A, B, C) for preliminary designs and number-based revisions (1, 2, 3) for released drawings.

Document what changes occurred in each revision using clear, actionable descriptions. Instead of “Updated part,” write “Increased wall thickness from 2mm to 3mm per stress analysis results.”

Establish approval workflows that require sign-offs before advancing revision levels. This prevents premature release of unfinished designs and maintains quality control.

Branching Workflows for CAD Projects

Feature-Based Branching

Create separate branches for major design changes or new features. This allows multiple engineers to work on different aspects of a product without interfering with the main design line.

When developing a new mounting bracket design, create a branch specifically for that work. This isolates experimental changes from the stable main branch until the design is proven and ready for integration.

Use descriptive branch names that indicate the feature or change being developed. Names like bracket_redesign_weight_reduction clearly communicate the branch’s purpose to other team members.

Release Branching Strategy

Maintain separate branches for different product releases or customer configurations. This allows you to continue development on future versions while maintaining the ability to make emergency fixes to released products.

Create release branches when designs reach a stable milestone. Tag these branches with version numbers that correspond to your product release schedule.

Apply critical fixes to release branches first, then merge them back to the main development branch. This ensures that important updates reach customers quickly while maintaining development momentum.

Parallel Development Workflows

When multiple engineers need to work on the same assembly, divide the work by subsystems or components. Assign clear ownership of specific parts or subassemblies to prevent conflicts.

Use placeholder components or simplified representations when one engineer’s work depends on another’s incomplete design. This allows parallel development to continue without blocking dependencies.

Schedule regular integration points where parallel work streams merge back together. Plan these sessions when all dependent work reaches compatible milestones.

Collaboration Protocols That Work

Check-In and Check-Out Procedures

Establish clear procedures for checking files in and out of version control. Require engineers to check out files before making any modifications and check them back in promptly when work is complete.

Communicate the scope and duration of planned changes when checking out files. If you’re planning a major redesign that will take several days, let your team know so they can plan their work accordingly.

Implement automatic reminders for files that remain checked out for extended periods. This prevents files from being inadvertently locked when engineers forget to check them back in.

Design Review Integration

Integrate design reviews into your version control workflow. Require formal reviews before major revisions advance to the next stage or before merging branches back to the main line.

Use your version control system’s commenting and annotation features to document review feedback. This creates a permanent record of design decisions and their rationale.

Schedule reviews at logical milestones in the design process. Review preliminary concepts before detailed design begins, and review detailed designs before releasing for manufacturing.

Communication Standards

Establish communication protocols that keep team members informed about design changes that might affect their work. Use your version control system’s notification features to alert relevant team members when files they depend on are modified.

Create shared documentation that explains the current status of different design areas. This helps team members understand what’s stable and what’s still changing.

Hold regular team meetings to discuss upcoming changes and coordinate work schedules. Face-to-face communication prevents many conflicts that purely digital workflows might miss.

Tools and Software Integration

CAD-Specific Version Control Systems

Several version control systems are designed specifically for CAD workflows. Autodesk Vault integrates directly with AutoCAD and Inventor, providing seamless check-in/check-out functionality within the CAD interface.

SolidWorks PDM (Product Data Management) offers similar integration for SolidWorks users. These tools understand CAD file relationships and can automatically manage dependencies when files are updated.

PTC Windchill provides enterprise-level CAD data management with sophisticated workflow capabilities. It supports multiple CAD formats and includes change management processes for complex organizations.

Integration with Existing Workflows

Your version control system should integrate smoothly with existing engineering workflows. Look for tools that work with your current CAD software without requiring major process changes.

Consider how version control integrates with downstream processes like manufacturing and documentation. Systems that can automatically generate bills of materials or export data for manufacturing planning provide additional value.

Evaluate integration with project management tools your team already uses. Version control systems that sync with project schedules help maintain alignment between design progress and project milestones.

Automation and Batch Processing

Automation reduces manual effort and prevents errors in version control workflows. Tools like CadShift can automate repetitive export and conversion tasks, ensuring consistent outputs while reducing the time engineers spend on manual file processing.

Set up automated backups of your version control repository. CAD files represent significant intellectual property that requires protection against data loss.

Implement automated testing where possible. Scripts that verify file integrity or check for broken references can catch problems before they affect other team members.

Implementation Best Practices

Team Training and Adoption

Successful CAD file version control requires buy-in from your entire engineering team. Provide comprehensive training that covers both the technical aspects of your chosen system and the workflows your team will follow.

Start with a pilot project that demonstrates the benefits of proper version control. Choose a project that’s important enough to matter but small enough to manage easily during the learning phase.

Assign version control champions within your team who can help others learn the system and troubleshoot problems. Having local experts reduces frustration during the adoption period.

Backup and Disaster Recovery

Implement robust backup strategies that protect your CAD files and version history. Use both local and off-site backups to protect against different types of disasters.

Test your backup and recovery procedures regularly. Knowing that you can recover from data loss reduces anxiety and encourages team members to experiment with new approaches.

Document recovery procedures so that any team member can restore files when necessary. Don’t make disaster recovery dependent on a single person’s knowledge.

Performance Optimization

Optimize your version control system for the file sizes and access patterns typical in CAD workflows. This might involve dedicated servers, high-speed network connections, or local caching strategies.

Monitor system performance and user feedback to identify bottlenecks. Slow version control systems discourage proper usage and lead to workaround behaviors that defeat the system’s benefits.

Consider geographic distribution if your team works from multiple locations. Local servers or caching can significantly improve performance for remote team members.

Common Pitfalls to Avoid

Inadequate File Locking

Failing to implement proper file locking leads to conflicts that are difficult or impossible to resolve. Always use your version control system’s locking features when working with CAD files.

Don’t rely on informal communication to coordinate file access. Even small teams benefit from formal check-out procedures that prevent accidental conflicts.

Avoid systems that don’t support file locking for CAD workflows. The merge capabilities that work well for text files don’t translate to binary CAD files.

Inconsistent Naming Practices

Inconsistent file naming creates confusion and makes it difficult to locate specific files or understand their relationships. Establish naming conventions early and enforce them consistently.

Don’t allow exceptions to naming conventions without good reasons. Each exception makes the system harder to use and understand.

Avoid names that depend on temporary information like project codes that might change. Use descriptive names that will remain meaningful throughout the product’s lifecycle.

Neglecting Dependencies

CAD assemblies create complex dependency relationships that require careful management. Track these relationships explicitly rather than relying on engineers to remember them.

Don’t update referenced files without considering the impact on assemblies that use them. Use your version control system’s dependency tracking features to identify affected files.

Avoid breaking existing references when reorganizing file structures. Plan reorganizations carefully and communicate changes to all affected team members.

FAQs

What’s the difference between CAD file version control and regular software version control?

CAD file version control deals with large binary files that can’t be merged automatically like text-based code. CAD systems require file locking mechanisms to prevent conflicts and need specialized tools that understand CAD file relationships and dependencies.

How do I handle large CAD assemblies with hundreds of components in version control?

Break large assemblies into logical subassemblies that can be managed independently. Use your version control system’s branching features to isolate work on different subsystems. Implement clear ownership rules for different assembly sections to prevent conflicts.

Can I use Git for CAD file version control?

Git can work for CAD files when combined with Git LFS (Large File Storage), but it’s not ideal for large teams or complex projects. Git’s distributed nature and merge-focused workflow don’t align well with CAD file characteristics. Centralized systems with file locking work better for most CAD workflows.

How often should I check in CAD files during development?

Check in files at logical milestones rather than on a fixed schedule. Good check-in points include completing a design feature, finishing a day’s work, or reaching a stable configuration. Always check in files before starting major changes or before other team members need access.

What happens when CAD software versions change and files become incompatible?

Plan for software version transitions by maintaining compatibility matrices and establishing migration procedures. Keep older software versions available for accessing legacy files. Consider using neutral file formats like STEP for long-term archival when software compatibility is a concern.

How do I manage CAD files that reference external libraries or standard parts?

Treat external references as dependencies that need explicit management. Either include referenced files in your version control system or maintain clear documentation about external dependencies and their versions. Establish procedures for updating external references across all affected files.

Should I store CAD files and their generated outputs (like PDFs or DXFs) in the same version control system?

Store source CAD files in version control but consider generated outputs separately. Outputs can be regenerated from source files and storing them creates unnecessary repository bloat. Use automated build processes to generate outputs consistently when needed — for example, batch DXF export from SolidWorks can regenerate all flat patterns from the source assembly on demand. Tools like CadShift automate these export workflows for consistent results.

Effective CAD file version control requires understanding the unique challenges of binary files, complex dependencies, and large file sizes. By implementing proper workflows, choosing appropriate tools, and training your team thoroughly, you can achieve the collaboration benefits of version control while maintaining the design integrity your engineering projects require.

The key is starting with clear procedures, enforcing them consistently, and continuously improving your processes based on team feedback and changing project needs. With proper version control in place, your engineering team can work more efficiently while reducing the risks of design conflicts and data loss.