How CADPreview Turns Your Git History Into Something Your Whole Team Can Read
By the CADPreview Team · Series: Git for Hardware Engineers
"The history was always there. The problem was who could read it."
Your hardware engineer has been doing everything right. Commits with meaningful messages. Tagged releases at every fabrication revision. Branches kept alive for every PCB revision still in production. The repository is clean, the history is there, and if you know how to read it, it tells you everything about where the design has been and where it is now.
Almost nobody on the team knows how to read it.
The firmware engineer cannot open a .kicad_pcb file. The supply chain manager has never cloned a repository. The programme manager's idea of checking the current revision is finding the schematic PDF someone shared on Slack, which may or may not be current. The information exists. It is just locked in a format and a toolchain that most of the team will never have reason to learn.
CADPreview is the layer between the two.
What "Connecting Your Repository" Actually Means
CADPreview connects to your KiCad project through GitHub. Once connected, the entire repository structure becomes navigable in a browser: every branch, every tagged release, every commit. The schematic, PCB layout, and BOM at any of those points render directly, no KiCad installed, no exports generated, no files downloaded to anyone's machine.
The design files stream from GitHub to the browser. They do not pass through or rest on CADPreview's servers. The source of truth stays where the engineer put it.
Your Git Discipline Becomes Their Navigation Layer
This is the thing worth understanding, because it changes how you think about the work you were already doing.
Every practice described earlier in this series produces something the rest of the team can now use directly.
A commit message explaining why a resistor value changed is not just version control hygiene. It is the note the firmware engineer reads six months later when they are trying to understand the pull-up network. A tagged release is not just a Git convention. It is the specific URL supply chain bookmarks when they need the BOM for the board that went to production. A branch kept alive after merge is not an untidy repository. It is the living record tied to a PCB revision that is still being assembled.
None of that required anything extra from the engineer. The commit message was written for themselves. The tag was created before handing off to the CM. The branch was kept open because the PCBs are still out in the world. CADPreview exposes all of it to the people who need it, in a form they can use without learning Git.
What This Looks Like in Practice
The firmware engineer checking a branch before it merges. The hardware engineer is reworking the power supply on a feature branch. Before it reaches main, the firmware engineer needs to verify that the GPIO assignments they are writing to have not changed. In CADPreview, they open that branch directly, navigate to the processor schematic sheet, and check. Not from a forwarded export. From the branch itself. The question gets answered before the branch merges, when fixing anything is still cheap.
Supply chain comparing two BOM revisions. The PCB is on rev-a. The original BOM is tagged rev-a.1. A component became hard to procure and an alternate was qualified, producing a new BOM tag at rev-a.2, same PCB, updated component. Supply chain has a CADPreview URL for each. The BOM diff between them is visible without generating any export. The PCB layout is identical. The distinction is precise, documented, and accessible to anyone with the link.
The programme manager asking what changed between prototype and production. Two tagged releases, one for the prototype build, one for the production release. Open both in CADPreview. Navigate to the same section of the schematic in each. The differences are visible without scheduling a meeting or interrupting the hardware engineer to reconstruct something they recorded at the time.
The Link, Not the File
Sharing a design in CADPreview is a one-time setup. Connect the GitHub repository, generate a Project Link, and send the URL. Anyone with that link can view the schematic, layout, and BOM in a browser without a CADPreview account and without installing anything.
The link points to the live repository. When the engineer commits a change, the person with the link sees it. There is no export to remember, no file to redistribute, no version to lose track of. The link and the repository stay in sync automatically, because there is nothing in between them.
What the Series Built
The four articles before this one covered why Git works for hardware despite not being designed for it, how to get a KiCad project onto GitHub in ten minutes with no command line, how to commit in a way that produces a readable history rather than a noisy one, and how branching maps onto the realities of hardware revision management.
The reason those practices matter beyond the engineering team is this: every good habit a hardware engineer builds in Git produces an artefact that CADPreview makes legible to the rest of the business. The commit discipline is team communication, deferred. The tagging convention is shared vocabulary. The branch structure is the revision history of physical objects that exist in the world.
Building the workflow for yourself turns out to be the same thing as building it for everyone else. CADPreview is how the rest of the team finds out.
CADPreview is a web-based viewer for KiCad projects hosted on GitHub. Connect your repository once, share a link, and your whole team sees the current schematic, layout, and BOM in a browser, on any branch, at any release, without installing anything.