Version control for KiCad projects
KiCad 6+ files are plain text, so git works. Here is a setup that stays clean, where git falls short for hardware review, and how BoardRepo fits in.
Commit these
The project file (.kicad_pro), schematics (.kicad_sch), the board (.kicad_pcb), project-local symbol and footprint libraries, sym-lib-table and fp-lib-table, and any 3D models the board references. That set reopens identically on another machine.
Ignore these
# KiCad backups and autosaves *-backups/ *.kicad_sch-bak *.kicad_pcb-bak _autosave-* *.bak # Caches and locks fp-info-cache ~*.lck *.lck # Fabrication outputs (regenerate instead of committing, or keep a release folder) gerbers/ *.zip
Autosave and backup files are the usual repo pollution. KiCad writes them next to the project, and committing them creates phantom diffs on every save.
Where git falls short for hardware
A schematic change shows up as an s-expression diff: coordinates, UUIDs, and reordered blocks. A one-resistor change can touch hundreds of lines, and a reviewer cannot tell a cosmetic move from a netlist change. Teams work around it with screenshot swaps or CI render pipelines such as KiBot, which help but need setup and maintenance per repo.
What BoardRepo adds
BoardRepo keeps a linear version history per project. Each upload or import becomes a version with its own file manifest, and every file is retrievable per version. The current version renders as schematic and PCB views with a generated BOM and gerbers, so reviewing a board means looking at the board, not at text.
That is the direction of the product: BoardRepo is becoming the versioning layer for electronics projects. Git stays the collaboration tool for source; BoardRepo tracks board revisions as rendered, reviewable states. Visual diffs between versions are on the roadmap.