Merge strategies — squash vs merge commit vs rebase
Two real merges already happened in this story. They used different strategies on purpose, and the reason is written into the Constitution.
Rewind and compare. When Rachit's two-week redesign landed on main back in Chapter 8, it arrived as a full merge commit — both parent lines preserved, every "wip" commit still individually there in history (messy as they were, which is exactly what motivated Chapter 9). When Ishaan's typo fix landed last chapter, it arrived as one single squashed commit — his original fix and Vidha's suggestion-commit both vanished into a single, clean entry.
Same merge button, different outcome, and it wasn't random. GitHub's merge button has three actual modes, and picking the wrong one for a given PR creates exactly the kind of unreadable history Vidha ran into.
The three modes, and what each writes onto main
| Strategy | What lands on main | Original commits kept? | Authorship |
|---|---|---|---|
| Squash and merge | ONE new commit with the total diff | ❌ collapsed into one | Whoever GitHub credits — normally the PR author |
| Create a merge commit | Every PR commit, plus one merge commit tying them together | ✅ all preserved | Each commit keeps its own original author |
| Rebase and merge | Every PR commit, replayed onto main's tip | ❌ same content, new hashes (Chapter 9's warning applies) | Each commit keeps its own original author |
Why Ishaan's PR got squashed
Ishaan worked alone. His PR's real content — fix a typo, apply a suggestion — is genuinely one idea, and nobody browsing main's history six months from now needs to see "fix typo" and "apply suggestion from review" as two separate entries. Squashing takes whatever mess accumulated during review (a suggestion-commit here, an "oops" there) and reduces it to exactly one meaningful line: this PR happened, here's what it did. That's what you saw land after his merge.
Why Rachit's redesign got a full merge commit instead
Here's the detail that actually matters, and it's not about length — it's about who wrote it. Suppose, hypothetically, that Anvesha's Tuesday color fix (the one that caused the announcement-bar conflict) had happened inside the same branch, as a commit she made directly on redesign/homepage, with a Co-authored-by: Anvesha trailer marking her contribution to a commit Rachit technically pushed. Squashing that PR would flatten it into one commit with exactly one author field — and unless the squash message is edited very carefully by hand, her name quietly disappears from the historical record of who actually wrote what.
This is precisely the failure Article XIV, §14.3(e) of the Constitution rules out by name — commit history and documented credit "shall not be rewritten or erased to the prejudice of any contributor." A merge commit keeps every individual commit intact, each with its real author still attached, which is the only one of the three modes that structurally guarantees co-authorship survives.
Why rebase-merge is off across the whole org
The third mode looks appealing at first glance — no squashing, no merge commit, just a perfectly straight line. But you already know its cost from Chapter 9: rebasing generates brand-new commit hashes for content that already existed. Two consequences follow directly. First, any signed commit (Chapter 12) loses its signature the moment it's replayed with a new hash — the signature was over the old commit, not the new one. Second, a contributor's own local copy of their PR branch now has different hashes than what's on main, a small but real confusion every single time. Accelerate turns this mode off at the org level rather than relying on everyone remembering not to click it.
The rule in one line, and how to apply it in practice
In practice, this is a thirty-second check before clicking merge: open the PR's "Commits" tab. One author throughout, no Co-authored-by: trailers anywhere in the messages — squash. Two or more distinct authors, or a trailer crediting someone beyond the PR's opener — merge commit. GitHub's dropdown on the merge button only offers the two modes the org allows, so there's no way to accidentally pick rebase-merge even by habit.
What a squashed commit actually looks like once it lands
commit 9f8e7d6c... Author: Ishaan <ishaan@example.com>
docs: fix typo in staging area explanation (#12)
* fix "seperate" -> "separate" in staging area doc
* apply review suggestion: reword the sentence for clarity
Closes #7GitHub pre-fills this from the PR title plus a bulleted list of the individual commit messages that got folded in. It's editable right there on the merge button before you confirm — worth a glance, since the auto-generated bullet list is sometimes worth trimming into something more readable.
Co-authored-by: trailer. Which merge mode is required to keep both people's authorship intact on main?The strategy is correct. But strategy alone doesn't stop a mistake from happening in the first place — nothing so far has actually prevented someone from pushing straight to main without a PR at all, or force-pushing over history by accident. That's the next layer, and it exists because relying on everyone remembering the rules, forever, isn't a real safeguard.