Feature developers
Break a 2,000-line feature into a chain of focused PRs your team can actually review — and keep coding while each one waits.
A single 2,000-line pull request is where review quality goes to die. Reviewers skim, bugs slip through, and the branch rots as main moves underneath it. Splitting by hand means juggling four or five branches and re-rebasing every one whenever an earlier change lands.
Structure the feature as it should be reviewed: schema first, then the data layer, then the API, then the UI. Each layer is its own branch created with gt create and opened as its own PR. Reviewers get a change small enough to reason about, and the dependency order is explicit.
You don't wait for the bottom PR to be approved before starting the next layer. Stack the next branch on top and keep going. When feedback lands on an earlier branch, you amend it and gt restack replays every branch above it automatically — no manual rebasing, no force-push archaeology.
As each PR is approved, gt land merges it and retargets the remaining PRs onto the updated trunk. The stack drains from the bottom up, and history stays linear and bisectable.
gt create schema start the bottom branch gt create api stack the next layer gt submit --stack open every PR at once gt restack replay the stack after an edit 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.