Version control for PCB designs
Most boards are versioned by folder name: rev_b_final, rev_b_final2, rev_b_final_SENT. It works until the fab asks which one they built. This is how to do better without turning every hardware project into a software project.
What a version is
A version is the complete state of the project at one moment: the schematic and layout, the libraries they reference, the 3D models, and the outputs you actually sent to a fab. Half a version is worse than none, because a layout without its library opens with missing footprints and a reviewer cannot tell whether the design or the archive is broken. Whatever tool you use, the unit to keep is the project folder, not the one file you edited.
Two things belong with every version: a short note saying what changed and why, and a way to get back exactly that state later. A folder name carries neither.
Where git helps, and where it stops
Git gives you both of those things for free, and if your team already uses it for firmware there is no reason to keep the board out of the repo. The KiCad version-control guide covers what to commit and what to ignore. The limit is review: a schematic change shows up as hundreds of lines of coordinates and identifiers, a binary Altium document shows up as nothing at all, and nobody can approve a board from that. Teams bolt on render pipelines to get pictures back out, which works and needs maintaining per repo.
The other limit is the audience. A repository is a fine archive for the people who commit to it. A client, a contract manufacturer, or a colleague in another department needs to see the board, not clone it.
Numbered versions on BoardRepo
BoardRepo treats each upload as a version. Upload the project folder as a zip, push it from KiCad, or let the GitHub App follow your default branch, and the board gets version 1, 2, 3, each with its own complete set of files, its own rendered schematic and PCB, and its own note. The board's link always shows the latest version; the history sits behind it, and every older version can be opened and downloaded as the exact zip it was.
Two versions can be compared visually: the changed components, routing and outline are highlighted on the board and schematic and listed by name, which is the review that a text diff cannot give you. If a revision turns out to be wrong, restore the previous version as the latest with one action; the restore is itself a new version, so nothing is rewritten.
Versioning for a team
When more than one person publishes, the question becomes who is allowed to. An organization owns its boards: admins decide which members can reach each board and who can publish a version, and the history stays with the organization when someone leaves. That replaces the shared drive and the emailed zip with one address that is always the current board.
A practical routine
Version at the moments that matter: before you send anything to a fab, after a review round, and whenever you would otherwise rename the folder. Write the note as the message to your future self who is holding an assembled board and wondering what this revision changed. Keep the outputs you ordered from inside the version, not in a separate folder, so the Gerbers and the design that produced them can never drift apart. Then send the link, not the zip.
Upload a board to start a history, or read BoardRepo vs GitHub if your board is already in a repo.
More in the guides.