Version Controlling Your CAD, CAM, and G-Code Files with Git: A Practical Workflow for the Maker Shop

If you write firmware for an ESP32 project or self-host services on a Raspberry Pi, you're probably already using git without thinking twice about it. But the same discipline rarely makes it into the CAD files, CAM toolpaths, and G-code sitting in a shop's "3D Printing" or "CNC Jobs" folder — usually a sprawl of final_v2_REAL_FINAL.stl files instead. Git isn't just for software, and applying it to your design and machining files solves real, recurring problems: knowing which version of a part actually got cut, recovering a toolpath after a bad edit, and collaborating on a project without emailing STEP files back and forth.

Why This Is Harder Than Versioning Code

Git was built for text files, where it can show you exactly which line changed between two versions. Most CAD formats (STEP, F3D, SLDPRT) and many CAM outputs are binary — git can still track them, but it can't show you a meaningful diff, and every save creates a full new copy in history rather than a compact line-level change. This isn't a reason to skip version control for shop files; it's a reason to be deliberate about what you track and how, so your repository doesn't balloon into gigabytes of near-duplicate binaries within a few months.

What to Track vs. What to Regenerate

File TypeTrack in Git?Why Source CAD files (F3D, STEP, SLDPRT, FCStd)YesThe actual design intent — everything else derives from this Parametric/text-based design files (OpenSCAD .scad, KiCad schematics/PCB)Yes — and these diff beautifully since they're plain textGit can show you exactly what changed between two design iterations Exported G-code / gcode-per-jobUsually not, or only the final "as-cut" versionRegenerable from CAM + source file; tracking every export bloats history fast STL/OBJ mesh exportsOptional — often better regenerated on demandDerived files; large binaries that change completely on every tiny tweak CAM project files (Fusion CAM setup, VCarve .crv)Yes, if your CAM tool saves toolpath setup separately from the modelCaptures feeds, speeds, and tool selection — expensive to reconstruct from memory

A practical rule: track anything you'd be upset to lose or need to explain later (source files, parametric definitions, final production G-code you actually ran), and treat everything freely regenerable from those sources as a build artifact you can recreate rather than something that needs its own history.

Setting Up a Repository for a Shop Project

If you're already running Gitea on a Raspberry Pi from our self-hosting guide, that's a perfectly good home for shop project repos — private by default, on your own network, with no size limits imposed by a third-party host. Structure a project repo something like this:

project-name/ source/ (CAD source files: .f3d, .step, .scad) cam/ (CAM setup files, per-machine) gcode/ (final, as-run G-code only — not every export) docs/ (photos, notes, material specs) .gitignore (exclude temp/autosave files, thumbnails, lock files)

A .gitignore file matters more here than in most code repos — CAD software loves to generate autosave files, lock files, and thumbnail caches that have no business being versioned. Fusion 360, SolidWorks, and Vectric products all leave predictable junk files behind; exclude them by extension pattern once and you won't think about it again.

Git LFS for Large Binary Files

Once you're tracking STEP files, STLs, or large G-code exports, a standard git repository will grow uncomfortably fast — every version of a 40MB STEP file is stored in full. Git Large File Storage (LFS) solves this by storing large binaries outside the main repository history and swapping in lightweight pointers, keeping clone and pull times reasonable. Setup is a one-time git lfs install plus a .gitattributes entry per file type you want handled this way (*.step filter=lfs diff=lfs merge=lfs -text, for example). This is worth doing from day one on a project rather than retrofitting it after your repository has already grown large — migrating existing history into LFS after the fact is possible but fiddly.

Commit Messages That Actually Help Later

"updated part" six months from now tells you nothing. For shop files, a useful commit message answers what changed and why it mattered enough to save a version — "Widened mounting slot 0.3mm after first fit test failed" or "Re-toolpathed pocket with 1/8in bit after 1/4in chipped out corner." This is the version control equivalent of the shop notebook habit good machinists already keep — you're just making it searchable and tied directly to the file that changed.

Tagging "As-Cut" Versions

For any part that actually got made — cut, printed, or milled — tag that specific commit (git tag as-cut-2026-09-15) so you can find the exact file state that produced a physical object sitting on your bench, even after the source design has moved on through several more revisions. This solves the extremely common shop problem of "which version of this file did I actually cut?" when you're trying to reproduce or repair a part months later and the current file in the folder has already diverged from what you ran.

Collaborating on Shared Machine Files

If more than one person in your shop or makerspace touches the same CNC job files or print profiles, git's branch-and-merge model handles this far better than a shared folder with everyone editing the same file — you avoid the classic "someone overwrote my changes" problem, and you get a clear history of who changed what and when. For binary CAD files specifically, true merging usually isn't possible (you can't automatically combine two people's conflicting edits to the same STEP file the way you can with text), so establish a simple convention: one person owns a given source file at a time, and everyone else works from copies or waits their turn, communicated through commit messages and branch names rather than a "final_v3_dont_touch" filename.

Where This Pays Off

The value of this workflow isn't obvious on day one — it shows up three months later when a customer asks you to reproduce an exact part, when a toolpath you deleted turns out to have been the good one, or when you're trying to figure out whether a design change happened before or after a part started warping in testing. None of this requires becoming a software developer; a handful of git commands (add, commit, tag, and occasionally log) cover the vast majority of what a shop actually needs, and the payoff compounds the longer a project lives.