Fast-moving teams
Don't idle waiting for a review. Stack the next change on top of the pending one and let stkd keep both in sync.
On teams with real review latency, the classic trap is a developer sitting idle because their next task depends on a PR that hasn't been approved yet. The alternative — one giant branch with everything in it — just moves the pain to the reviewer.
Stack the dependent change directly on the open PR with gt create. You keep shipping; the reviewer still sees each piece as a small, isolated diff. Nobody is blocked and nothing is bundled into an unreviewable mega-branch.
When the bottom PR is approved and merged, gt sync deletes the merged branch, restacks the branches above it onto the updated trunk, and retargets their PRs. The chain flows downstream on its own instead of leaving you to rebase four branches by hand.
The optional self-hosted dashboard gives leads a live, shared view of every open stack and its PR status, so review bottlenecks are visible before they stall the team.
gt create stack the next task on the pending PR gt sync heal the stack after the base merges gt log see the whole stack at a glance New to these? Follow the quickstart or read how stkd works.
Install stkd in under a minute. Apache-2.0, single binary, every major platform.