Splitting one big pull request into five smaller ones doesn’t automatically make review faster. It just moves the complexity from the diff to your head, unless something keeps track of the order for you.

What stacked PRs solve, and what they don’t

GitHub’s stacked pull requests, now in public preview, turn one large change into an ordered chain of pull requests, each one a focused layer that targets the layer below it instead of main. Reviewers get a smaller diff per PR. Merge the top of a ready stack, and everything beneath it merges in one motion. When a lower layer merges on its own, the layers above it rebase automatically instead of you doing it by hand.

That solves the size problem. It doesn’t solve the orientation problem: you still need to know which layer you’re looking at, what it depends on, and whether the layer underneath it is even ready yet. A stack you can’t see is just a large PR wearing a chain instead of a single diff.

The new PR sidebar in GitLens 19

GitLens 19 adds a dedicated PR sidebar alongside the existing worktree, branch, tag, and agent views. It lists your open pull requests and lets you click straight into the graph to check one out and start reviewing. Now that GitHub has shipped stacked PRs natively, GitLens shows them as a stack in that same sidebar, instead of as a flat, unordered list of PRs that happen to be related.

How do you see a stacked PR’s order and dependencies in GitLens?

Click into a PR that’s part of a stack, and the PR details panel shows where it sits in the stack order relative to the other layers. You’re not cross-referencing branch names against a mental model of what depends on what. The order is just there.

This is a first pass, and GitLens says so

GitHub’s stacked PRs only reached public preview on July 30, 2026. GitLens 19 is our first shot at supporting them, built and shipped fast enough to be useful the same month the feature landed. We’d rather ship a solid first version and keep refining it than sit on stacked PR support until it’s fully polished while the feature is already in your repos.

Why this matters more than it might look like

GitHub built stacked PRs largely because AI agents can generate more pull requests than a normal review process can absorb. Breaking changes into layers is the fix on the writing side. But if the tooling around it doesn’t show you the stack, you’ve just added a second thing to track manually on top of the review itself. The PR sidebar is where GitLens keeps that from becoming its own chore.

Try it

GitLens 19 is available now. Update GitLens and open the new PR sidebar to see your stacked pull requests laid out in order, with a direct path into the graph to review them.

FAQ

What are stacked pull requests? A stacked pull request setup breaks one large change into an ordered chain of smaller PRs, each targeting the PR below it instead of the main branch. Each layer is reviewed on its own, and merging the top of a ready stack merges every layer beneath it in one operation. GitHub moved this into public preview on July 30, 2026.

Does GitLens support GitHub’s stacked pull requests? Yes. GitLens 19 adds a PR sidebar that displays stacked PRs as a stack, and the PR details panel shows where each pull request sits in the stack order.

How do I review a stacked PR without losing track of the order? Open the PR sidebar in GitLens 19, select a pull request that’s part of a stack, and the details panel shows its position relative to the other layers before you jump into the graph to review it.