Git Was Built for Code. Hardware Engineers Use It Anyway. Here's Why.
By the CADPreview Team · Series: Git for Hardware Engineers
"You don't use Git because it was designed for hardware. You use it because nothing else comes close to solving the problem it solves."
Let's be honest about the objection first, because it is a fair one.
Git was designed by software engineers, for software engineers, to manage text files. Source code. Line-by-line diffs. Merge conflicts that a human can read, understand, and resolve in a text editor. That is the world Git was built for.
A PCB layout is not a text file. Two engineers cannot sensibly merge their changes to a copper pour. The diff output for a schematic, in a format designed for human readability, is not always human-readable. There are entire categories of Git's power that simply do not transfer to the physical design domain.
If you have tried Git on a hardware project and found it clunky, or been told it was the right tool and found the reality unconvincing, that experience was not wrong. The friction is real.
So why do hardware engineers use it anyway? Because the problem it solves is real too, and nothing else solves it better.
The Problem Git Is Actually Solving
Version control for hardware is not really about code-style merging. It is about one thing: knowing what the design was, at any point in time, and being able to get back to it.
When something goes wrong at bring-up, and the bring-up behaviour does not match what the engineer expected, one of the first questions is: has the design changed since the last working revision? In a team without version history, answering that question means asking the hardware engineer to reconstruct it from memory, or digging through file timestamps, or comparing the schematic open on screen to a PDF someone saved two weeks ago and hoping the PDF was current.
With a version-controlled repository, that question has a definitive answer. Open the history. Look at what changed between the tagged release and the current state. The answer is there, exact, timestamped, and not dependent on anyone's memory.
That is the core of it. Not merging. Not branching. Not CI pipelines. Just: what did this design look like at this point, and what has changed since.
Why KiCad Changes the Equation
The reason Git works meaningfully better for KiCad projects than for Altium projects comes down to file format.
KiCad stores schematics, layouts, and project files as plain text. The .kicad_sch and .kicad_pcb files are human-readable, structured text. That means when you look at the diff between two commits, you can see that a resistor value changed, that a net was renamed, that a component was moved. Not perfectly, not with the elegance of a Python diff, but meaningfully. Enough to understand what happened.
Altium's native formats are binary. A binary diff tells you that something changed. It does not tell you what. That is a fundamental limitation, and it is one reason so many Altium teams fall back on folder-based version management even when they know better. With KiCad, the text-based formats make Git genuinely more useful, not just philosophically correct.
The Objections, Taken Seriously
"Merging PCB files is a nightmare."
Yes. It is. Two engineers should not be making layout changes to the same file at the same time without coordination. Git does not make that easy, and you should not expect it to. The answer is not to pretend the problem does not exist. It is to structure the work so the situation rarely arises: one engineer owns the layout at a time, changes happen on branches, and merges go through a review step. Git's branching model is how you enforce that discipline, not how you resolve conflicts after the fact.
"My team doesn't know Git."
This is the most common real obstacle, and it is a process problem more than a technical one. The threshold for useful Git on a hardware project is low. You need commits with meaningful messages, a tagging convention for releases, and a shared repository. That is achievable without anyone on the team being a Git expert, and tools like GitHub Desktop remove the command line entirely. The next article in this series walks through exactly that setup.
"We already track versions with filenames."
board_v4_FINAL_rev2_send_this_one.kicad_pcb. If that looks familiar, you already understand the problem. Filename versioning breaks the moment two people are working on the same project, and it never recovers. You cannot reconstruct the history. You cannot compare two arbitrary revisions. You cannot tell, six months later, which file represents the revision that actually went to the manufacturer.
What Git Gives You That Nothing Else Does
A complete, recoverable record of every meaningful state the design passed through. Not the states you remembered to archive. Not the states where someone happened to send a file to a colleague. Every commit you made.
When a component changed and the firmware engineer is targeting the old pinout, you find the commit where it changed and you have the context for why. When the CM asks whether the board they are quoting matches the one you sent last month, you compare the tagged release to the current state and you have a definitive answer. When a compliance question surfaces about what the design looked like at a specific point in the project, you navigate to the relevant tag and you are looking at it.
These are not edge cases. They happen on most hardware projects. The difference between having answers and not having answers is whether you built the history while the project was moving.
Beyond the Engineering Team
There is one more argument for Git that has nothing to do with version diffs or merge strategies.
A Git repository on GitHub is a single source of truth that the whole team can connect to, not just the engineers. CADPreview plugs directly into that repository. Once connected, anyone on the team, your firmware engineers, your supply chain team, your programme manager, can open any branch or tagged release in a browser and see the current schematic, layout, and BOM without installing anything.
That visibility only exists if the repository exists. Every commit the hardware engineer makes is automatically reflected for the rest of the team. No export step. No Slack attachment. No stale PDF. The act of committing, which the engineer is doing for their own benefit, is also the act that keeps everyone else in the loop.
That is the kind of payoff that makes a tool worth learning even when it was not built for your domain.
What's Next
The next article covers the practical setup: getting a KiCad project onto GitHub in ten minutes, with no command line and no prior Git experience required.
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.