Stacked pull requests break large changes into small, reviewable pull requests. They’re an ordered series of pull requests that each represent focused layers of your change. With stacks, you can…
Maybe I just don’t know enough how these work, as I’ve never heard of stacked prs before.
What does the workflow look like? Can the first PR be merged and deployed without the other prs being approved and merged first? Or do they all need to be approved and it all gets merged together?
We’re using agentic coding heavily, but still reviewing code to help us steer the software architecture and keep our understanding of the implementation. We generate large changes quickly, but need to break them into smaller, logically ordered PRs for review.
It’s nice for the reviewer to be able to look ahead through the full change, so they see can check the big picture, rather than merging a couple of PRs and then spotting that the abstractions are wrong.
PR stacks work very well for providing this kind of visibility, but are annoying to merge. After one PR in the stack is merged, the next PR needs to be rebased onto and targeted to the updated main branch. With our branch protection rules, this triggers another CI run and dismisses the PR approval, requiring human intervention.
It would be much nicer to have the reviewer go through all the PRs and then merge the stack in one go.
Maybe I’m being dumb but I don’t see the point? Just be disciplined in creating smaller PRs?
That is the point. By making smaller PRs, you inevitably end up with dependencies between them. So you’d like to stack them.
Maybe I just don’t know enough how these work, as I’ve never heard of stacked prs before.
What does the workflow look like? Can the first PR be merged and deployed without the other prs being approved and merged first? Or do they all need to be approved and it all gets merged together?
I haven’t used it yet but assuming they did it right, yes you can merge the PRs sequentially.
Assuming it’s like gitlab’s stacked PRs, all the merge requests are independent. It’s basically “just” rebasing the stack once the bottom gets merged.
Isn’t that what this does? You do a bunch of small PRs then stack them into the full feature
We’re keen to use stacked PRs at work.
We’re using agentic coding heavily, but still reviewing code to help us steer the software architecture and keep our understanding of the implementation. We generate large changes quickly, but need to break them into smaller, logically ordered PRs for review.
It’s nice for the reviewer to be able to look ahead through the full change, so they see can check the big picture, rather than merging a couple of PRs and then spotting that the abstractions are wrong.
PR stacks work very well for providing this kind of visibility, but are annoying to merge. After one PR in the stack is merged, the next PR needs to be rebased onto and targeted to the updated main branch. With our branch protection rules, this triggers another CI run and dismisses the PR approval, requiring human intervention.
It would be much nicer to have the reviewer go through all the PRs and then merge the stack in one go.