How would you land a chain of five dependent GitHub pull requests without blocking the rest of your team?

## What a stack is on GitHub GitHub always diffs a pull request against its base branch. If you point B's base at A's branch instead of the default branch, B's diff shows only B's work. Repeat this and you get a stack: five reviewable units, each small, each dependent on the one below. This is the standard answer to "my change is 3,000 lines and nobody will review it" without resorting to a single unreviewable pull request. ## The mechanics that decide whether a stack is pleasant or painful **Automatic retargeting.** When you merge a pull request and delete its head branch, GitHub retargets any open pull requests that used that branch as their base, pointing them at the merged pull request's base. So merging A quietly moves B to target the default branch. This is the single most important platform behaviour to know here, and it is why stacks work at all without tooling. **The merge method dominates the pain.** Retargeting changes the base *pointer*; it does not rewrite B's commits. If A merged with a merge commit, A's commits are still present on the default branch with their original identities, so B's copies of them are the same objects and B's diff collapses correctly to just B's work. If A was squash-merged or rebase-merged, the default branch now holds *different* commits carrying the same changes, while B still carries the originals. B's diff then shows A's changes again and conflicts are likely, so B has to be replayed onto the updated default branch before it is reviewable. This is precisely the point where the tree split matters: the replay itself is a Git operation, but the choice that created the problem is the repository's merge-method policy. **Review discipline.** A stack asks reviewers to hold context across five pull requests. Keep the upper ones as drafts until their parent is nearly landed, describe the stack in each body ("2 of 5; depends on #401"), and put the risky change as high in the stack as you can so the safe foundation lands early. ## Alternatives you should weigh out loud The interviewer is usually probing whether you reach for stacking reflexively. Three alternatives: - **Independent small changes behind a feature flag.** Each merges to the default branch immediately, in any order, with no stack to maintain. This is normally the better default: the dependency was often only in your head, not in the code. - **A shared integration branch.** All five pull requests target one long-lived branch that merges to the default branch at the end. Simpler than a stack for the authors, but it defers integration risk and the final merge is large. - **One pull request with clean commits.** Sometimes honest: if the five parts are genuinely inseparable, one pull request reviewed commit by commit beats five pull requests nobody can reason about individually. ## Operating a stack that has to exist - **Land bottom-up, quickly.** Every day the bottom sits unmerged, the default branch drifts and the whole stack ages. - **Prefer merge commits for the intermediate entries** if your repository allows a per-pull-request choice, because preserving commit identity is what makes retargeting cheap. - **Re-run checks after retargeting.** A child that was green against its parent's branch is not necessarily green against the default branch; the required checks must pass in the new context before merging. - **Do not delete branches manually mid-stack.** Deleting a parent's branch while children are open, without merging, orphans them; let the merge do the deletion so retargeting fires. - **Watch for a merge queue.** Where one is in use, entries land through the queue rather than instantly, so the stack drains at the queue's pace and it is worth checking how your team's queue treats dependent entries. ## What a strong answer sounds like Name the topology (each pull request based on the previous), name the platform behaviour you are relying on (automatic base retargeting on merge), name the failure mode (squash or rebase merging leaves the children carrying duplicate commits), and then step up a level: stacks are a workaround for changes that could not be made independently, so the first question is whether feature flags and smaller independent changes remove the dependency entirely. Owning that framing — rather than just describing the mechanics — is what makes this a lead-level answer.