Mastering Stacked Pull Requests (PRs)

The useful part

This is my personal findings and recommendations weaved into a cheatsheet for getting good at using Stacked PRs. Do note that not every user story implementation needs to be broken down and stacked into multiple PRs. At the end of this article, I've given a quick rule of thumb guide to help you decided whether the task you're working makes sense to be a set of Stacked pull requests.

How it works

• A stacked PR is a chain of branches where each one targets the branch below it instead of main: main в†ђ auth-layer в†ђ api-routes в†ђ ui-components Each PR shows only the diff for its own layer.
• You don't wait for the auth review to finish before opening the API PR вЂ" you stack on top and keep working.
• The goal is not fewer changes вЂ" it's changes that a reviewer can hold in their head.
• A 1,400-line change becomes 4 PRs of ~350 lines each, one focused concern per PR.
• A good stack has layers that are each atomic (small, coherent) and safely revertible.

What to take from it

If a middle layer would break main on its own, the boundary is wrong вЂ" repartition before you submit.

Details worth keeping

Each layer is independently revertible and independently correct. When the bottom merges, GitHub cascades the rebase automatically. The skill is the layer boundary, not the CLI.