The Git Chassis: Five Primitives

What you'll be able to do: look at any software project on GitHub and name the five moving parts — Repo, Branch, PR, CI, Merge — say what each one protects, and follow a real change from "idea" to "safely part of the product" without touching a terminal.

Choose your door

Builder — jump to the Builder Track. Open a real repo and click around before reading anything.
Architect — jump to the Architect Track. See the whole pipeline as one diagram first.
Translator — start at the Bridge below.
Validator — work the Gates at the bottom, one at a time, in order.

Translator Bridge

A repo is like a classroom master binder: the one official copy of every lesson plan, and it remembers every version that ever existed.

Branch = photocopying a section to mark up at your desk. The binder stays untouched while you experiment.
PR (pull request) = putting your marked-up copy in the principal's tray with a note: "I propose we replace pages 12–14 with these."
CI = the school's checklist clerk who automatically proof-checks every proposal — spelling, page numbers, whether it contradicts the fire-drill policy — before the principal even looks.
Merge = the principal signs off and the new pages go into the master binder. From that moment, it's what everyone teaches from.

Where the analogy ends: a binder holds paper — the master binder can't test itself. In software, CI actually runs the product against dozens of checks every single time, and a locked main branch physically refuses the merge if any check fails. The principal in our world literally cannot sign a proposal the clerk has stamped red. Also: photocopies drift from the binder, but a branch can be refreshed from the master at any time — the copy machine runs backward.

The five primitives

Primitive	What it is	What it protects
Repo	The one official home of the project + its full history	Truth: "where does this project actually live?"
Branch	A parallel copy where change happens safely	The working product, from your experiments
PR	A proposed change, visible and reviewable before it lands	Everyone's right to see what's changing and why
CI	Automatic checks that run on every proposal	The product, from broken or self-graded work
Merge	The human decision that a checked change becomes real	The human's place as the final gate

One sentence to keep: change happens on a branch, gets proposed in a PR, gets tested by CI, and only a human merge makes it real.

Builder Track (DO FIRST)

Open any public repo on GitHub you can browse — a large open-source project works well. Find the branch picker (top-left of the file list). Count the branches. Each one is a safe copy.
Click Pull requests → open a closed (merged) one. Read the description like a proposal memo. Find the Files changed tab — that's the marked-up photocopy.
On the PR page, find the checks section (green checkmark near the merge area). Click it. That's CI's stamped report.
Find the purple Merged badge. That was the human gate — a person clicked that, after the checks went green.
Now say out loud what you just walked through: branch → PR → CI → merge. You've traced the whole machine.

Architect Track (MODEL FIRST)

 idea → [Branch] → work happens → [PR opened] → [CI runs checks]
                                                      │
                                            red ──────┤────── green
                                             │                 │
                                     fix & push again   [Human merges]
                                                               │
                                                        main (the product)

The design insight: every arrow is a narrowing. Anyone can branch; only a PR makes change visible; only green CI makes it mergeable; only a human makes it real. Main stays trustworthy because nothing reaches it without passing every gate. This is the same shape the honest reporting in a tool I built follows: a number + the assumption behind it + a cited basis — a claim only counts when it carries its evidence, exactly like a PR only counts when it carries green checks.

Validator Gates

Pass each gate before moving on. These are permission to advance, not hazing.

Gate 1: Name the five primitives without looking.
Gate 2: Which two primitives exist purely to protect something rather than to do something? (CI protects the product; merge-as-human-gate protects judgment.) Explain why in one sentence each.
Gate 3: True or false: work done on a branch changes the product immediately. Say why.
Gate 4 (own words): Write the branch → PR → CI → merge journey as if explaining to a fifth grader. No jargon allowed except the four names themselves.

Lesson complete — you can now read any GitHub project like a floor plan. Next: Lesson 2, where the machine learns to say "I don't know."