Small pull requests depend on an ordered branch chain
GitHub Stacked PRs gives a name and a command set to a practice experienced Git users already perform by hand. One branch sits on the trunk, another sits on that branch, and each becomes a pull request whose base is the layer below it. Reviewers see a focused diff instead of the whole feature. The extension records the order in .git/gh-stack, then handles navigation, submission, synchronization, rebasing, restructuring, and merging.
The repository is larger than the simple idea suggests. Our checkout at commit ab00aa4 contained 181 files and about 52,387 lines of source. That size makes sense once the terminal interface, Git recovery logic, GitHub stack integration, documentation site, and command surface are counted. The benefit is practical: a developer can move up or down the chain, while a reviewer gets pull requests with the intended base already assigned.
The CLI covers the whole stack, including recovery
The quick start is short: initialize a stack, add layers, push branches, view the result, and submit the pull requests. Beyond that path, checkout can find a stack by number, pull request, URL, or branch. modify can drop, fold, insert, reorder, or rename layers in a preview before applying the change. rebase records interrupted state and exposes continue and abort commands rather than leaving recovery to undocumented Git archaeology.
Our install pulled 203 Go packages in 29 seconds, and the build took another 29 seconds. There is no separate service, database, Docker image, or application account to operate. You do need GitHub CLI v2.0 or newer, an authenticated GitHub account, and push access to the repository. The extension also enables Git rerere during initialization, which can save repeated conflict resolutions when the same change travels through several layers.
What happened when we ran it
Our sandbox installed the project in 29 seconds and built it successfully in 29 seconds. The test command finished in 73 seconds: Go reported 15 passed and 0 failed out of 15. Those results came from an unprivileged Debian container with 3 CPUs and 8 GB of RAM, no secrets, and commit ab00aa4. We found no failed command or warning in the supplied result that needs explaining away.
The scan found 3 CI workflow files, no Dockerfile, and no tests directory. The absence of a tests directory did not mean the project lacked runnable tests, since go test found and passed 15 of them in package files. The measurement covers installation, compilation, and the available suite. It does not prove that pushes, branch rules, merge queues, renamed repositories, or GitHub API operations will behave correctly under a team's policies.
Success messages are the current trust problem
Issue 472 describes gh stack sync warning that its push failed, then printing that the stack synced and returning exit code 0. Issue 467 records another contradiction: a one-branch stack reports a successful submit, yet gh stack merge says it was never submitted because GitHub stack objects require at least two pull requests. These reports matter more than cosmetic roughness because scripts and people use command status to decide whether remote state changed.
GitHub listed 112 open issues, excluding pull requests, when we checked, while the repository page showed 120 combined issues and pull requests. A push on August 26, 2026 and detailed reports with maintainer discussion show an active project rather than an abandoned v0.1.0 tag. Still, automation should verify remote branch tips and pull request existence after submit or sync. A green line from the extension is not enough for a release pipeline yet.
Worktrees and rewritten history need deliberate handling
Local metadata lives in the Git directory. Issue 459 says a stack initialized inside a linked worktree keeps its state under that worktree's Git directory; removing the worktree can remove that local record. The reporter also notes that reopening the branch in the main worktree does not preserve the same local stack view. Teams assigning related branches to several coding agents in separate worktrees should reproduce this behavior before standardizing on the extension.
The 73-second test run cannot exercise a company's branch protections or conflict patterns. Rebase walks from trunk toward the top, and push may use force-with-lease after rewritten commits. The README provides abort paths and restores branches when some cascading operations fail, which is the right design for dangerous work. Even so, developers need clean working trees, reflog familiarity, and an agreement about who may rewrite a shared layer while reviews are open.
v0.1.0 is useful, but narrow alternatives may fit better
Release v0.1.0 was published on July 29, 2026. It added atomic stack merging and fixed stale-trunk handling plus duplicate-history cases after amended parent commits. The README now documents remote stack reconciliation, merge queues, headless flags, and an agent skill installed through gh skill. This is unusually direct documentation for an early release, and the GitHub ownership makes its integration with GitHub stack objects the main reason to choose it.
A clean build and 15 passing tests make gh-stack a low-cost experiment for a team already using GitHub CLI. Git Town is broader and works as a host-independent workflow layer. git-spice stays close to stacked branches, while git-branchless goes deeper into local commit-graph work. Pick gh-stack for GitHub-native stack objects and a familiar gh interface, then keep a human watching every command that claims it changed remote state.