Quiz - Git as shipping discipline

Your team squash-merges every PR by default. For which one of these PRs would a senior actually reach for a real merge commit instead, preserving the branch’s individual commits on main?

A normal feature branch with the usual “wip”, “fix typo”, and “address review” commits on it.

A deliberate refactor where each commit is a self-contained step — “rename the type”, then “move the file”, then “update the call sites” — that you genuinely want recorded separately on main.

A large PR that touches a lot of files, so squashing it would produce one commit with a big diff.

Squash-merge is the default precisely because feature branches are scratchpad noise. The exception is the rare multi-commit refactor where each commit is a meaningful, deployable checkpoint worth keeping on main — not “this PR is big”. Size alone is never the trigger; whether the individual commits are each a clean story is.

A test that passed on a known-good commit weeks ago is failing now, and there are roughly forty commits in between with no obvious culprit. Which tool is built for exactly this, and why does the chapter’s squash-merge habit make it trustworthy here?

git bisect — and because every commit on main is one complete, deployable change, each midpoint it checks out genuinely worked or genuinely didn’t.

git reflog — and because it keeps a 90-day journal of every commit, the broken one is still recoverable.

git blame — and because squash-merge keeps one commit per change, the annotation points straight at the PR that introduced the regression.

bisect binary-searches a known-good-to-bad range — log₂(N) tests instead of N. On a messy history its midpoints can be half-built “wip” commits that fail for unrelated reasons, poisoning the search; squash-merge guarantees each midpoint is a whole, deployable PR, so its result is meaningful. reflog recovers lost work, and blame answers “who wrote this line” — neither searches a range for a regression.

Why does this chapter teach git reflog before you’ve ever lost work, rather than when you need it?

The reflog has to be enabled with a config flag before it starts recording, so you must set it up in advance.

The moment you’d reach for it is the moment you think “I just lost my work” — the worst possible time to be reading docs for a command you’ve never run.

Reflog entries for unreferenced commits expire after 30 days, so you have to recover work the same day you create it.

The reflog records automatically — no setup flag — so it’s already capturing your history. The point of front-loading it is psychological: by the time a sinking feeling tells you work is gone, you need to already know git reflog exists, not be discovering it under stress. (The 30/90-day expiry is real, but it’s a limit, not the reason to learn it early.)

A junior optimizes for shipping fewer PRs because batching feels efficient. Why does an experienced engineer optimize for the opposite — more, smaller PRs?

Smaller PRs run CI faster, so the team merges more changes per hour.

GitHub ranks smaller PRs higher in reviewers’ queues, so they get attention sooner.

Small forces one logical change, which makes the PR reviewable, which makes it cleanly revertible — the three properties reinforce each other so each PR fits in one reviewer’s head.

Small, reviewable, reversible aren’t three separate goals — they’re one property seen from three angles. Small almost forces a single logical change; a single logical change is one a reviewer can hold in their head and one a single git revert undoes cleanly. CI speed and queue ordering aren’t the reason; reviewability and reversibility are.

You’re unsure your approach is right and want a colleague to sanity-check the direction before you build the rest. You’re tempted to just open a draft PR “to be safe” on most of your work. Why is making drafts your default a mistake?

Drafts can’t run CI, so you’d lose the early-warning signal from the checks.

Reviewers learn that drafts aren’t ready and skip them, so a PR you open as a draft can sit ignored for days.

A draft PR can’t be linked to a CODEOWNERS file, so the right reviewers never get auto-requested.

You add /app/billing/ @org/billing-leads to .github/CODEOWNERS and confirm the billing leads now get auto-requested on every billing PR. Yet those PRs keep merging without their approval. What’s missing?

The Require review from Code Owners rule in the ruleset — without it, CODEOWNERS only auto-requests reviewers who can be ignored.

The line needs to move to the top of the file, since CODEOWNERS uses first-match-wins ordering.

The Require approvals: 1 rule, which is what actually counts a code owner’s approval.

The file is the data (who owns what); the rule is the switch (whether that data blocks a merge). Without Require review from Code Owners, owners are auto-requested but ignorable. CODEOWNERS is also last-match-wins, not first; and Require approvals: 1 would be satisfied by any reviewer, not specifically the owner.

GitHub offers two mechanisms for protecting main: branch protection rules and rulesets. For a team standing up a repo in 2026, which is the right default, and what’s true of the other?

Use rulesets — the newer default that targets multiple branch patterns, layers, and audits bypasses; branch protection rules are the legacy mechanism, still functional, that older tutorials show.

Use branch protection rules — the stable, battle-tested mechanism; rulesets are still in preview and shouldn’t gate production merges.

They’re interchangeable aliases for the same settings page, so it makes no difference which you pick.

Quiz - Git as shipping discipline

Quiz complete