ne place

cu documente multe maiii t about stacked pull requests stacked pull requests are two or more pull requests in the same repository, where the first, or bottom, pull request targets the stack's trunk — usually your repository's default branch, such as main, though it can be any branch, such as a release branch each subsequent pull request targets the branch of the pull request below it ┌── feat/frontend → pr #3 (base feat/api endpoints) ← top ┌── feat/api endpoints → pr #2 (base feat/auth layer) ┌── feat/auth layer → pr #1 (base main) ← bottom main (default base branch) stacked branches form a dependency chain, where each branch builds on the one below it foundational changes such as shared types and database schema go in lower branches, and code that depends on them, such as api routes and ui components, go in higher branches each pull request in a stack represents a discrete, reviewable change of one or more commits you can review and iterate on each pull request independently, and each one shows only the diff for its layer and the changes between its branch and the branch below it the key principle if code in one layer depends on code in another, the dependency must be in the same branch or a lower one create a new branch when you start a different concern that depends on what you've built so far for example, when you switch from backend to frontend work, move from core logic to tests, or when the current branch is already large enough to review why use github stacked pull requests finish one change and move straight onto the next stacked pull requests let you open a new pull request on top of one that is still open during a large project, your next change may depend on work that hasn't merged yet instead of waiting for it to merge, with a stack, you can keep building with each pull request in a stack containing one focused change, reviewers see a small diff for each layer instead of the large pull request smaller pull requests are faster to review, less likely to be skimmed, and less likely to go stale and develop merge conflicts fit for high volume development when you generate a lot of code at once, often with ai agents, a stack gives each change a place to go an agent completes one task, then starts the next task that builds on it that sequence maps directly onto a stack one pull request per task, each based on the one below stacks let you record those dependencies explicitly instead of combining unrelated changes into a single branch advantages of using stacked pull requests in github without stacked pull requests, breaking a large change into smaller, dependent pull requests creates extra work branch management rebasing and keeping branches in sync across dependent pull requests is tedious and error prone rules and ci branch protection rules and ci checks often only trigger for the bottom pull request in the chain, making it hard to know the true status of the rest review context reviewing a single change out of context from the rest of the stack can reduce review quality stacked pull requests address these problems by treating the chain of pull requests as a connected unit while keeping each layer small and focused rebasing rebasing is the trickiest part of working with stacks, and github handles it automatically you can trigger a server side cascading rebase from the pull request, or run a local cascading rebase with the gh stackextension in github cli when you merge a pull request at the bottom of the stack, the remaining branches are automatically rebased so the next pull request targets the default base branch where can you use stacked pull requests stacked pull requests are available in the following github cli github website github mobile programmatic support via webhooks, rest api, and graphql for agents, via the gh stackskill note stacked pull requests require all branches to be in the same repository cross fork stacks are not supported stacked pull requests are not supported in github desktop in github cli the gh stackextension in github cli handles the local development workflow you can create and track branches in the correct dependency order, keep branches rebased, push branches, create and link pull requests, and navigate between layers see stacked pull requests cli commands on the github website when a pull request is part of a stack, you will see a stack icon at the top of the pull request with a number indicating which layer you're viewing a stack map appears in the merge box it shows every pull request in the stack and its status, and lets you navigate to any layer with one click the trunk (default base branch) is at the bottom, with each pull request in the stack targeting the branch of the pull request below it programmatic support via webhooks, rest api, and graphql stacked pull requests are available programmatically, so you can integrate them into your own tools, automation, and dashboards webhooks include a stackobject in pull requestevent payloads, so your automation can respond when a pull request joins, moves within, or leaves a stack the rest api reads a pull request's stack membership and provides endpoints to list, create, extend, and dissolve stacks the graphql api exposes read only stackfields on a pull request for querying the stack and the pull request's position in it rules, ci, and merging rules and ci enforcement stacked pull requests support github actions workflows the merge requirements for any pull request in the stack are determined by the bottom pull request's base branch, typically main branch protection rules, such as codeowner approvals, are enforced on every pull request in the stack, even mid stack pull requests that don't directly target your default branch ci checks triggered by pull requests on your default branch run for all pull requests in the stack, not just the bottom one this ensures that every layer of the stack meets the same quality bar before it can merge merging you can merge your entire stack, a single pull request, or a portion of the stack spanning multiple pull requests the entire stack does not need to merge at once, but pull requests must merge from the bottom up merge the entire stack at once by merging the top pull request every pull request below it comes with it merge part of the stack by merging a mid stack pull request the pull requests below it merge too, and the pull requests above stay open and automatically re target the stack's base branch stacks support merge commit, squash, and rebase merge methods, and they are merge queue aware the resulting commit history is the same as merging each pull request individually, starting from the bottom note if you merge via the api and want to use stacked pull requests, you'll need to use the asynchronous merge api for stacks see rest api endpoints for pull requests