Branching Strategies for PCB Design — Do They Even Make Sense?
By the CADPreview Team · Series: Git for Hardware Engineers
"In software, a merged branch is finished. In hardware, a merged branch is a physical object that might still be on a shelf somewhere."
The honest answer is: yes, but not in the way you might expect.
Where the Software Model Breaks
In software, branching works because merging works. Two engineers edit different parts of the codebase and Git combines them. Try that with a .kicad_pcb file and the result is a broken board file. Git will produce output. It will not open cleanly in KiCad.
The fix is not clever tooling. One engineer owns the layout file at a time. Explicit handoff. Git enforces nothing here. Discipline does.
What Branching Is Actually For
Two things.
Isolation of intent. Uncertain work, a power supply redesign that might not pan out, should not destabilise main while it is in progress. A branch contains that uncertainty. If the work succeeds, it merges. If not, the branch is abandoned and main is untouched.
Permanent revision records. This is where hardware diverges from software practice entirely.
Branches Do Not Die After Merge
In software, you delete a feature branch after it merges. In hardware, that would be a mistake.
A realistic scenario. An engineer works on rev-a, the board goes to production, and the branch is merged to main. Later, a component becomes hard to procure. rev-b is cut from main, the part is updated, and the revised board goes to production.
Now both revisions are live. rev-b PCBs are being built. rev-a PCBs are still in stock and being assembled. A solution is found to use the rev-a boards with an alternative component. The PCB does not change. The BOM does. The engineer goes back to the rev-a branch, updates the schematic, and issues a new BOM.
That commit will never be merged to main. Intentionally. Main is on rev-b with a different footprint. The BOM change is only valid for rev-a PCBs. An unmerged commit in software means unfinished work. In hardware it can mean a deliberate, permanent divergence between physical revisions that are both in production at the same time.
The rev-a branch is not finished. It is a living record tied to a physical object that exists in the world.
Tags as BOM Revision Markers
The branch identifies the PCB revision. Tags identify the BOM revision within that branch.
rev-a.1— first released BOM, at the point the board went to productionrev-a.2— updated BOM for the alternate component, same PCB
Supply chain gets a specific CADPreview URL for each. Both are accessible in a browser. The BOM diff between them is visible without generating any export. The PCB layout is identical. The distinction is precise and documented.
The Pull Request as Design Review
When a branch is ready to merge, a pull request creates a structured review event. Reviewers get a CADPreview URL for the branch. Comments go into the PR thread. Approval is recorded. The merge happens when review is satisfied.
For a small team this takes less overhead than a meeting, and it leaves a permanent record of what was reviewed, who approved it, and when.
When Not to Branch
One engineer. One board. Linear work toward a first prototype. Commit to main, tag releases, and skip the branching overhead entirely.
The test is simple: does this work need to be isolated from main while it is in progress? If not, there is no reason for a branch.
The Workflow
Think of it this way. main always reflects the latest released design. When work on a new revision begins, a new branch is created from main, which at that point reflects the released state of rev-a. All changes happen on that branch. Old revision branches are never deleted. They stay open because the PCBs they represent are still out in the world. BOM changes on an old revision go onto that branch and get a new tag. They never come back to main.
The branch is the engineering record of everything ever decided about that PCB revision, across its entire production life.
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 tagged release, without installing anything.