Branches, Pull Requests and Release Lanes

Branches, Pull Requests and Release Lanes
Branches, Pull Requests and Release Lanes The words everyone uses and nobody defines. Agentic SDLC · The Multiverse School 1 · WHAT A BRANCH IS A branch is a save point you diverged from. Your work happens on the copy; the shared line is untouched until you decide otherwise. main feature/knockback you branch here …and this rejoin is the pull request Each dot is a commit — a save point with a message saying what you did. 2 · WHAT THE TWO WORDS MEAN PULL the change. The commits on your branch — the thing you want pulled in. REQUEST permission. You are asking, not doing. Somebody — or some check — says yes. MERGE the request granted. Only now do your commits exist on the shared line. So a pull request is: a diff — what changed, line by line a place to argue about it before it is real a gate — CI runs, and a human ticks boxes a URL you can send someone The agent-era reason it matters If anyone can push to production, eventually someone will — at the worst possible time. Agents included. Protect the branch or the rule is a habit, not a control. 3 · WHY NOT JUST MERGE IT 83 open pull requests on campus, right now Not because nobody looked. Because merging is the risky half. A fix can introduce a new bug. Worse: fixing a feature that never worked uncovers the five bugs the breakage was hiding. A broken feature is often concealing the broken rest of that feature. So you don't read 183 files. You open the preview URL and walk a test plan: sign in as a moderator, try to kick an admin, check the padlock holds. 4 · RELEASE LANES PRs never target production. They target a named lane, and the lane is promoted on purpose. PATCH broken now · ships ~daily UNSTABLE new behaviour · ships at cohort end PRODUCTION what your users are actually running hotfix docs feature feature pull requests, each targeting a lane promote promote a human pulls this trigger, never an agent PREVIEW URL one per deploy lane, not per PR A running copy of that lane, at a URL you can click. This is how you review 183 changed files without reading 183 changed files: you open it and you walk the test plan. Cap how many are live at once — they quietly eat the box. preview preview A release branch that has drifted from production is how the merge that breaks everything gets built. Keep them in sync continuously. 5 · WHAT A WORKTREE IS One repository, several checked-out copies on disk at once. .git agent A · patch agent B · feature you · reviewing Two agents editing one working tree is the #1 way a run derails. Give each its own. 6 · WHAT THE NUMBERS ARE FOR 1 . 17 . 3 MAJOR MINOR PATCH It is a promise about what breaks, not bookkeeping. It is what makes "we regressed" checkable — you can name the version it worked in and the version it didn't. It tells the agent when a bug was introduced, so it can go and look there. It tells anyone downloading your thing what they are getting. Here: MINOR is cohort-tied, and even means stable, odd means unstable — the number itself says whether you're on a tested line. 7 · THE LEDGER GitHub issues are the ledger. Not your memory, not chat scrollback. If it isn't an issue, it doesn't exist. Agents produce work faster than you can hold it in your head. Errors become issues automatically — nobody has to notice first. Open the issue before you build the thing.

Tour mode

Space / next · previous
Home / End first / last
19 jump to frame

Explore mode

Click any highlighted region to zoom in.
Click further-in regions to drill deeper.
Backspace / Esc — zoom back out
O — return to overview

Anywhere

M — toggle mode
T — toggle frame list
F — fullscreen · R — restart
0 / 0 Tour