gh-stack for Safer Infra Reviews
GitHub's gh-stack is trending because it solves a common review problem: infrastructure work often arrives as one oversized pull request. That is painful for reviewers, risky for deployers, and hard to bisect when production behavior changes.
Stacked PRs are not only a developer convenience. They are an operational control. They let teams review schema changes, Terraform modules, rollout wiring, and service code in the order they will actually land.
What is gh-stack?
gh-stack is a GitHub CLI extension for managing stacked branches and pull requests. A stack is an ordered list of branches where each layer builds on the one below it. The bottom branch targets main or another trunk branch, and each higher PR targets the branch below.
That means reviewers see the focused diff for each layer instead of a blended mega-diff. The tool handles the tedious pieces: creating branches, setting correct PR bases, pushing the stack, submitting linked PRs, rebasing layers, and navigating up or down the chain.
It also has a useful AI-agent detail: the project supports installing a gh-stack skill so coding agents know how to work with stacked PR workflows instead of flattening everything into one branch.
Key Features
- Layered PRs: Split a migration into small branches such as config, API, worker, and UI.
- Correct PR bases:
gh stack submitcreates one PR per branch and points each PR at the layer below it. - Cascading rebase:
gh stack rebasefetches trunk and rebases the stack from bottom to top. - Stack navigation:
gh stack view,checkout,up, anddownmake long-running work easier to inspect. - Local metadata: Stack state lives under
.git/gh-stack, so it does not add repo files.
Installation
You need the GitHub CLI first. Then install the extension:
gh extension install github/gh-stack
gh stack --help
For agent-assisted repositories, install the companion skill:
gh skill install github/gh-stack
SRE Workflow Example
Use stacks when a change has clear dependency layers but should not be reviewed as one block.
gh stack init terraform-network-policy
# commit the base network policy changes
gh stack add service-rollout
# commit deployment and service changes
gh stack add dashboards-and-alerts
# commit observability updates
gh stack push
gh stack submit
A reviewer can approve the network policy first, then the rollout, then dashboards and alerts. If the rollout layer needs work, the dashboard PR can stay visible without blocking the lower review.
Operational Tips
Keep each layer independently understandable. A good stack layer should have a clear rollback story, a focused test signal, and a short PR description explaining what the next layer depends on.
Use stacks for risky infrastructure refactors, Kubernetes migrations, CI/CD rewiring, and multi-service incident fixes. Avoid them for tiny changes where one PR is clearer.
Make your merge queue and branch protection rules explicit. Stacked PRs are powerful, but production repositories still need required checks, CODEOWNERS, deployment locks, and human approval for sensitive paths.
Conclusion
gh-stack is worth testing if your platform team struggles with huge infrastructure PRs. It keeps review context small, preserves dependency order, and gives SREs a cleaner audit trail for changes that affect production.
If your team wants AI-assisted incident workflows with strong operational guardrails, Akmatori helps SRE teams investigate alerts, coordinate response, and automate safe infrastructure actions. Powered by Gcore for global infrastructure reliability.