Version control for PCB designs prevents the chaos of multiple engineers working on different versions, lost changes, and the nightmare of manufacturing the wrong revision. While software developers have used Git for decades, PCB designers in India often still manage revisions through folder names like “PCB_v3_final_FINAL2”. This guide explains how to implement proper version control for PCB projects using Git, naming conventions, and release management practices.
Table of Contents
- Why Version Control for PCBs
- Revision Naming Conventions
- Using Git for PCB Files
- Design Change Workflow
- Release Management
- Engineering Change Notices
- BOM and Fabrication File Sync
- Frequently Asked Questions
Why Version Control for PCBs
- Track every change with who, when, and why
- Revert to any previous version if a change causes problems
- Multiple engineers can work on the same project without overwriting each other’s work
- Clear audit trail for compliance (ISO 9001, automotive IATF 16949)
- Align PCB revisions with firmware versions and BOM revisions
- Prevent manufacturing wrong revision — the released version is always clearly identified
Revision Naming Conventions
| Stage | Format | Example | Meaning |
|---|---|---|---|
| Prototype | vX.Y | v0.1, v0.2, v0.3 | Pre-production iterations |
| Pilot | vX.Y | v1.0 | First production-intent release |
| Production | vX.Y | v1.1, v1.2 | Minor revisions (component changes, fixes) |
| Major revision | vX.0 | v2.0 | Significant design change (new MCU, layout change) |
Rules:
- Major version (X): Increment when the board is not backward-compatible — different form factor, connector changes, or major circuit redesign
- Minor version (Y): Increment for compatible changes — component value changes, additional test points, copper pour fixes
- Never reuse revision numbers. If v1.2 was manufactured, the next revision is v1.3, never v1.2a or v1.2-fixed
Using Git for PCB Files
KiCad files are text-based (S-expression format) and work well with Git. Eagle and Altium use binary formats that require special handling.
Repository structure:
project-name/ ├── hardware/ │ ├── schematic/ # KiCad .kicad_sch files │ ├── pcb/ # KiCad .kicad_pcb files │ ├── library/ # Custom symbols and footprints │ ├── fabrication/ # Generated Gerber files (per release) │ └── bom/ # BOM exports ├── firmware/ # MCU firmware source code ├── mechanical/ # Enclosure CAD files ├── docs/ # Datasheets, design notes ├── .gitignore # Ignore backup files, caches └── README.md # Project overview and revision history
.gitignore for KiCad:
*.kicad_pcb-bak *.kicad_sch-bak *-backups/ fp-info-cache *.dsn *.ses
Design Change Workflow
- Issue/ticket: Create a ticket describing the required change (bug fix, feature request, component change)
- Branch: Create a Git branch from the current release (e.g., “fix/replace-regulator-u3”)
- Design: Make the schematic and PCB changes on the branch
- Review: Peer review using diff tools (KiCad visual diff or schematic PDF comparison)
- Test: If prototyping, order and test the modified board
- Merge: Merge the branch into the main release branch
- Tag: Create a Git tag with the new revision number (e.g., “v1.3”)
- Release: Generate and archive fabrication files for the tagged revision
Release Management
- Tag every released revision in Git:
git tag -a v1.3 -m "Replace U3 regulator, add C12" - Generate Gerber files from the tagged revision and store in the fabrication/ directory
- Export BOM from the tagged revision
- Create a release zip containing: Gerbers, drill file, BOM, assembly drawing, fab notes
- Store the release zip in a shared location (Google Drive, S3, or Git release)
- Update the silkscreen revision number on the PCB before generating release files
Engineering Change Notices
An Engineering Change Notice (ECN) formally documents a design change for production:
- ECN number: Sequential (ECN-001, ECN-002)
- Description: What changed and why
- Affected documents: Schematic rev, PCB rev, BOM rev
- Impact: Does this change affect form, fit, or function?
- Approval: Sign-off by designer, reviewer, and production manager
- Implementation date: When the change takes effect in production
For companies pursuing ISO 9001 certification (increasingly important for Indian electronics exporters), ECNs are a mandatory part of the quality management system.
BOM and Fabrication File Sync
- Always regenerate the BOM and fabrication files from the same source revision
- Include the revision number in file names:
project-v1.3-gerber.zip,project-v1.3-bom.csv - Verify that the silkscreen revision on the PCB matches the file revision
- For JLCPCB/PCBWay orders, upload files directly from the release archive — never from the working directory
Frequently Asked Questions
Can I use Git with Altium or Eagle?
Altium uses binary file formats that Git cannot diff meaningfully. Use Git for version tracking and backup, but rely on Altium’s built-in comparison tools for reviewing changes. Altium 365 offers native version control with visual diffing. Eagle XML files are somewhat Git-friendly but diffs are hard to read.
Should fabrication files (Gerbers) be in Git?
Yes, for released versions. Store generated Gerbers in a “releases/” or “fabrication/” directory and tag them with the version number. This ensures you can always reproduce exactly what was manufactured for any past revision.
How do I handle shared component libraries?
Use a separate Git repository for shared component libraries. Reference it as a Git submodule in your project repositories. This way, library updates propagate to all projects, and each project can pin a specific library version.
What if I need to modify a board that is already in production?
Create an ECN documenting the change. Branch from the production release tag, make the change, increment the minor version, and follow the full release process. Never modify the production files in place — always create a new revision.
Browse PCB prototyping boards, soldering tools, and electronics supplies at Zbotic PCB & Prototyping — fast shipping across India.
Add comment