Hardware designs already have the same problems that pushed software teams toward version control: experiments diverge, fixes need review, releases must be reproducible, and yesterday’s working state matters.
But putting a .kicad_pcb file in a repository is only the beginning.
What Git should own
Git should own the canonical, human-authored and tool-authored source of the design:
- schematics and PCB layout;
- local symbol and footprint libraries;
- mechanical constraints and enclosure models;
- scripts that generate or verify the design;
- release manifests and the checksums of manufacturing outputs;
- the engineering notes needed to understand why a decision was made.
That history makes a board forkable, reviewable, and recoverable. A teammate can inspect the exact change that moved a connector or opened a solder-mask aperture instead of comparing two opaque ZIP files.
What Git should not be asked to do
Access control, background job claims, invitations, and mutable project metadata do not belong in Git commits. fabPlane keeps those in PostgreSQL. Large durable Git objects are stored through the Git backend, while generated renders and fabrication previews use a separate artifact bucket.
This separation matters. A cached PNG can be regenerated. The source commit that produced it cannot.
A hardware commit should explain a physical change
Good hardware history describes the effect on the object:
Add front-mask apertures to FL1 and FL2 so all sixteen filter pads can be soldered.
That is more useful than update board. It gives reviewers a claim they can verify against the PCB diff, DRC report, and exported mask layer.
Releases are evidence bundles
A manufacturing release should identify one source commit and collect the outputs produced from it: Gerbers, drills, BOM, placement data, renders, DRC/ERC summaries, and checksums. Those files are evidence about a commit—not a replacement for it.
Generated previews are disposable artifacts. The repository remains the source of truth.