Version Control

What this book is

A production discipline, not a developer habit

The entry for Book 31 was gone from build_all_docx.py — not the file, which still existed with a name in the right place, but the correct registration block, silently clobbered by a bulk find-and-replace that swept through the build registry and erased four lines. The build ran clean. No errors, because the script exited fine — it just produced nothing for Book 31. Three days later a production run came up short, the docx in the build directory turned out to be six versions stale, and the registration block pointed at the wrong output path. git log --all found the commit that had fixed this exact bug once, and one command recovered the four lines. The build ran clean again.

That's what version control is for in an AI project, and it isn't what developers usually mean by the phrase. It wasn't source code at risk — it was the build registry, the script wiring a finished book into the pipeline, the configuration that made a month of manuscript work actually producible. This book is not Git mechanics; the man pages already cover those. It's the judgment behind the discipline: what belongs under version control when you're running a language model at production scale, what breaks when you skip it, and how commit history becomes a working audit trail for a system that generates new files every day.

What you’ll learn

Ten chapters, from what belongs to what scales

• what-belongs — The asset categories an AI project produces that most developers have never had to version — build registries, prompt templates, policy files, plan documents.
• what-never — What must never be committed: credentials, large media, model artifacts, proprietary prompt content, and why each category causes real damage that doesn't announce itself.
• commit-discipline — Commit message and staging discipline for a repo where a script entry is as load-bearing as any source file.
• branching — Branching for active work in a production pipeline that can't stop generating output while a change is in progress.
• git-as-audit-trail — Using git history as a forensic record of what an agent was asked to do and when, not just a change log.
• private-identifiers — Keeping private identifiers out of worked examples and commit history without breaking the example's usefulness.
• auth-switching — GitHub CLI auth-switching for projects that span multiple accounts or organizations.
• repo-structure — Repo structure decisions that keep generated content, source material, and tooling from tangling into one undifferentiated tree.
• scaling — What changes about commit discipline as the number of daily-generated assets grows past what one person can review by hand.
• conclusion — Version control as a production discipline for a system that generates new assets every day, not a developer habit applied out of convention.

From the book

A preview

Developers working at this scale for the first time tend to version the manuscript and ignore everything else. This is exactly backwards. The prose can be regenerated. Configuration that produced it often cannot.

Who it’s for

Anyone running a language model in daily production

This is for anyone running a language model in daily production — generating manuscripts, build scripts, prompt templates, or policy files — who wants commit history to function as a forensic record instead of an afterthought. It pairs naturally with Managing a Catalog at Scale (Book 54) for the metadata and build-registry discipline this book's git practices protect.

A longer excerpt is available to newsletter subscribers.

Buy Ebook on Amazon