Stacked pull requests, read in the order they were written.
A stack is cheap to write and expensive to review: four pull requests that only make sense bottom-up, scattered across a list that knows nothing about their order. PR Flow shows the chain as one journey — the same way on GitHub, GitLab, Gerrit and Azure DevOps — while every layer stays a review in its own right.
Everyone tells you to split the change. Nobody tells you how to review it.
Breaking a large change into a chain of small ones is good practice and better for the author. The cost lands on the reviewer, who has to reconstruct an order the tools do not show — and it gets worse the moment a stack spans more than one provider.
The order is invisible
In a list sorted by activity, layer 3 can sit above layer 1. Nothing on the row says which change it builds on, so you find out by opening it and recognising code from a pull request you have not read yet.
Every provider models it differently
GitHub has native stacks. GitLab chains merge requests by branch. Gerrit has relation chains built from commit ancestry. Azure DevOps has nothing at all. Four vocabularies, and none of them help once your review week spans two of them.
Reviewing the wrong diff
Open the top of a stack cold and the diff looks enormous, because half of it is context from below. You either re-read work you already approved or approve something you never actually looked at.
Guesswork dressed up as structure
A tool that infers dependencies from “blocked by #123” in a description will be confidently wrong sooner or later — and a wrong order is worse than no order, because you stop checking it.
Position on the row, a map in the detail, a pager in the review.
Every layer carries its place in the chain.
A neutral 2/4 marker sits next to the branch wherever a pull request appears, and layers of the same stack that land next to each other are grouped visually. Grouping never hides work: each layer keeps its own attention reason and its own unread state, because a stack is not a second inbox.
- Position markers on the row, before you open anything
- Adjacent layers of one stack grouped together
- A filtered-out sibling is announced — “2 more in stack” — never silently dropped
- The position travels with the PR into the tray, notifications and AI prompts
The whole chain, trunk at the bottom.
Open any layer and the map shows the stack it belongs to: each layer's title, number, review state and checks, which one you are on, and which one PR Flow suggests next. It also says where the membership came from, so you always know whether you are looking at provider truth or an inference.
- A layer PR Flow already tracks opens in place
- One it doesn't offers Open here, which starts tracking it
- Every map is labelled with its evidence — native, branch chain, ancestry or inferred
- Loose references stay under Related changes, never as layers
One layer at a time, with the stack still on screen.
Start a review and the chain comes with you: a compact Layer 2/3 pager in the header, [ and ] to move down and up, and a caption naming exactly which changes you are reading — so a small review never feels like the whole stack again.
- A warning when a lower layer moved and this one may need a rebase
- Submitting applies to the layer you are on, and says so
- PR Flow offers the next layer — it never opens a review on its own
- Nothing posts until you press submit, and PR Flow never merges
Work through your chains, or get them out of the way.
Filters gains a Stacks section: show only stacked pull requests when you want to clear your chains, hide stacked ones when you want everything else, or pick a stack by name — each is named after the change everything else builds on — to narrow the board to that chain. Pick several to compare them.
- The section only appears when something on your board is actually stacked
- It stays visible while a mode is set, so a filter can never hide its own off switch
- Hiding stacks clears a selected chain, since together they would match nothing
Four models of a stack, one way to read them.
PR Flow only calls something a stack when your provider says it is one, and every map carries the evidence it was built from. Lower-confidence evidence never overrides a confirmed chain, and a confirmed chain is never quietly downgraded.
GitHub — native stack
GitHub's own stack fields, in the order GitHub reports. Read-only, and cheap: the position rides along on the poll the board already makes, so the board pays nothing for it.
GitLab — branch chain
An open merge request joins a stack when it targets another open merge request's source branch — GitLab's own rule, applied the same way PR Flow applies every other one.
Gerrit — relation chain
Commit ancestry, straight from the relation chain. Same-topic changes and “submitted together” are not ancestry, so they are never presented as layers.
Azure DevOps — inferred, and labelled
Azure exposes no stack information at all, so PR Flow infers a chain from branches only when it is unambiguous — and always says on the map that it was inferred.
A sentence in a description is not a dependency
blocked by #123, part of, a pasted link: all of it is real context, and none of it is a confirmed order. It appears under Related changes, separately from the stack, so the map keeps meaning exactly one thing. That separation is the point of the feature.
Partial knowledge, shown as partial.
A map you cannot trust is worse than no map, so PR Flow never smooths over the parts it cannot see.
Stack features follow the PR stack switch in Settings → Features. Turn it off and markers, the map and layer navigation all disappear, while Related changes keeps working. On a Team or Enterprise license an administrator can set it for the whole organization — see pricing, or the stacked pull requests documentation.
- A layer you do not have access to keeps its row and says it is not visible to you
- A stack longer than PR Flow can show reads “of at least 6” rather than claiming a total
- If the provider cannot be reached, the last confirmed map stays, marked stale, with a Retry — never replaced with a guess
- A server too old to expose stacks simply shows none, with nothing else affected
Stacks are one layer of the queue, not the whole thing. The same board ranks GitHub pull requests, GitLab merge requests and Gerrit changes by what needs you next.
How stacks actually work here.
Do I need a stacking tool like Graphite or spr?
Can PR Flow create, rebase or merge a stack for me?
Does a stack become one big review?
Does "blocked by #123" in a description count as a stack?
What happens on GitHub Enterprise Server, or an older GitLab?
Does this slow the board down?
Keep reading
Pull request dashboard
One ranked queue for pull requests spread across repos and providers.
Pull request review queue
How PR Flow decides which review needs you next, and why that beats a feed.
GitHub pull request dashboard
Review requests, your own PRs and stale threads on GitHub, in one queue.
Gerrit code review dashboard
Gerrit changes, patchsets and review labels alongside your other work.
Review the stack from the bottom up, for once.
Install PR Flow, open the top of your next chain, and let it tell you what you are actually reading. Free for 14 days.