In GitHub, what does the Require linear history branch rule actually prevent?

## The rule in one sentence A branch with "Require linear history" enabled will not accept an update whose new commits include any commit with more than one parent. That is the whole rule. Everything else people believe about it — that it forces rebasing, that it bans merging, that it requires squashing — is a consequence of that single shape constraint, or a misunderstanding of it. ## Why anyone wants it A linear default branch has one property teams value: the first-parent history is the complete list of landed changes, in landing order, and every commit on it is a state the branch actually passed through. That makes `git log` readable without graph gymnastics, makes bisecting straightforward, and makes "what shipped between these two points" a simple range. The cost is that the individual authoring history of each change is either flattened (squash) or replayed onto the tip (rebase), so the exact commits the author wrote are not what the branch records. ## What it does to GitHub's merge buttons GitHub offers three ways to land a pull request, and the repository's settings decide which are available at all: - **Create a merge commit** — produces a commit with two parents (the base tip and the PR head). This is precisely the shape the rule forbids, so it cannot be used on a linear-history branch. - **Squash and merge** — collapses the pull request into a single new commit with one parent on the base. Always legal under the rule. - **Rebase and merge** — replays the pull request's commits onto the base tip; every resulting commit has one parent. Also legal. So the rule does not "choose squash for you"; it eliminates one option and leaves the team to pick between the other two. Because a disabled-by-rule button is a confusing user experience, the usual configuration pairs the rule with the repository's *Pull Requests* settings: untick **Allow merge commits**, leave squash and/or rebase ticked. The rule is the enforcement (it also covers pushes, not just merges); the settings are the ergonomics. ## What it does not do - **It does not forbid merging inside your branch.** Merging `main` into your feature branch creates a merge commit on the *feature* branch. Whether that ever reaches the protected branch depends on the landing method: squash collapses it away, rebase replays only your own commits. A merge-commit landing would carry it in, which is exactly why that button is gone. - **It does not require an up-to-date branch.** Freshness against the base is the separate "require branches to be up to date" condition on required status checks. - **It does not prevent force pushes.** Blocking history rewrites is the separate rule (`non_fast_forward` in rulesets). A linear branch can still be rewritten unless you block that too, and a linear-history rule with force pushes allowed is a fairly weak guarantee about what the branch's history means. - **It does not apply retroactively.** Merge commits already in the branch's history stay there; the rule is evaluated on new updates only. ## Interaction with other platform features A merge queue is compatible with linear history: the queue merges entries using the configured merge method, so pick squash or rebase for that branch. If a repository requires linear history but has left merge-commit as the queue's method, entries will fail to land — a small configuration trap worth checking when a queue mysteriously cannot merge anything. Revert pull requests are also worth a thought. GitHub's *Revert* button opens a pull request containing a revert commit, which is an ordinary single-parent commit and lands fine under the rule. Reverting a *squashed* pull request reverts the whole change as one unit, which is usually what you want and is one of the practical arguments for squash on a linear branch. ## Configuring it In classic branch protection it is a checkbox on the rule. In a ruleset it is a rule object of type `required_linear_history` in the ruleset's `rules` array, which means an organization can apply it to many repositories at once by targeting branch-name patterns, and can see it listed alongside every other rule that applies to the branch. ## Interview framing Define the rule by the commit shape it rejects, then translate that into the concrete effect people feel: the merge-commit button disappears, squash and rebase remain, and repository settings should be aligned so nobody is offered a button that cannot work. Adding that it is orthogonal to force-push blocking and to base freshness shows you are not lumping all branch rules into one blur.