Stacked pull requests are now generally available on every github.com plan, GitHub said in its October 6 changelog entry. That single fact changes the calculus for teams that were waiting on GA status before letting engineers build dependent branches into their default review flow. Stacked PRs let a contributor chain multiple pull requests together so later branches build on earlier, unmerged ones, which in theory shortens review cycles for large changes. GitHub's announcement does not include version numbers, usage data, or a timeline for when the feature moved out of preview.
Two pieces of the rollout are not finished. GitHub says support for GitHub Enterprise Server is coming but names no version or date, so self-hosted shops cannot plan a cutover yet. Stack auto-merge, which would let an entire chain merge once checks pass, is described as rolling out over the next few weeks rather than live today. That gap matters because auto-merge is the part most likely to interact with branch protection rules, required status checks, and merge queues, the exact machinery platform teams tune to keep deploys predictable.
For on-call engineers, the relevant risk is not the feature itself but what happens when a stack partially merges or a check fails mid-chain. If one PR in a stack is blocked, downstream PRs built on top of it inherit that state, and platform operators should check whether their required-check configuration treats a stacked chain as independent units or as a single gated sequence. Teams running custom merge automation, bots that watch for merge events, or deploy pipelines triggered off PR merges should verify behavior against a stack before auto-merge reaches their org, since the mechanics of multi-PR merges are new enough that edge cases are untested in production at scale.
GitHub's post confirms GA availability and the GHES roadmap item; it does not confirm rollout percentages, a GHES version target, or whether auto-merge will be opt-in or default-on when it lands. Anything beyond those two confirmed points is not stated in the announcement, and teams should treat timelines for GHES support as unscheduled rather than imminent. Engineers should also check whether existing webhook integrations and CI systems key off individual PR merge events in ways that assume one base branch per merge, since stacks complicate that assumption by design.
The practical move for platform teams is to audit branch protection and merge queue rules against a test stack before enabling the feature broadly, particularly on repos with required reviewers or status checks tied to deploy automation. Auto-merge for stacks is not live yet. It is scheduled to roll out over the coming weeks, which gives operators a short window to confirm that merge queue behavior, required checks, and any merge-triggered automation handle a chain of dependent PRs the same way they handle a single one.