Stacked diffs vs feature branches — when each one wins

It’s tempting to frame stacked diffs as the new, better feature branch — but that misses the point. Stacked diffs aren’t a replacement for feature branches; they’re a tool for the specific case where a feature branch would be too big. Knowing which to reach for, and when, is the difference between feeling productive and feeling like you’re fighting your tools.

Here’s a side-by-side.

The two workflows in one picture

Feature branch:

main
 └── feature/big-thing          (you, reviewer, PR #100)
                                 4,200 lines, 38 files, 5 reviewers, 142 comments,
                                 in review for 6 days

Stacked diffs:

main
 └── feature/thing-base          PR #100  (in review)
      └── feature/thing-step-2    PR #101  (in review)
           └── feature/thing-step-3 PR #102  (draft, you're still editing)
                └── feature/thing-step-4 ◉   (you, in progress)

Two workflows, one piece of work. The question is which shape matches the work you have.

When feature branches win

Feature branches are great for:

Single-file or single-concern fixes. Bumping a dependency. Fixing a regression. Renaming a class. The whole change naturally lives in one PR.
Spikes and prototypes. When you’re exploring and don’t yet know the final shape, splitting prematurely is wasted ceremony.
Hotfixes. When something is on fire and the goal is “land this in 15 minutes, not 4 days,” the overhead of a stack works against you.
Pair-programmed work. Two people on one branch with frequent pushes is awkward to do as a stack; the dependent branches get out of sync with each other.
Tiny teams with abundant review bandwidth. If you have one teammate who reviews your PRs in 20 minutes, the wait time you’d save by stacking is small.

If your PR is going to be under ~400 lines and review-and-merge inside a day, just use a feature branch.

When stacked diffs win

Stacks pay off when:

The change is too big for one PR. Anything that’s going to land >800 lines, touch >10 files, or span >2 days of work is a candidate. Each step in the stack can land as it’s ready.
You’re blocked by review latency. If review takes longer than you’d like, the first fix is to make PRs smaller — and stacking is what lets you do that without serialising your work.
The change has natural seams. Schema → backend logic → frontend wiring → tests. Each layer can land on its own and the next layer builds on it.
You want to keep coding while review happens. This is the killer feature. The author’s clock and the reviewer’s clock run in parallel; you stop waiting for the previous PR.
You’re working with an AI agent. Agents that produce many small, focused changes work much better in a stacked workflow than in one giant PR (see Using stkd with Claude Code).
Reverts need to be surgical. If you might want to roll back part of a feature without rolling back the whole thing, stacks make that trivial.

A useful heuristic: the more total time the work will take, the more stacking helps. The break-even is somewhere around “this will take 2+ days and 800+ lines.”

A direct comparison

Concern	Feature branches	Stacked diffs
PR size	Typically large (everything that’s “the feature”)	Each one is small; total work is the same
Review latency impact	You wait for the whole PR before next work	Each PR reviews in parallel with your next work
Author parallelism	Sequential: implement → review → fix → land → next	Concurrent: implement → submit → keep coding on top
Merge complexity	One merge	N merges, but each is small and bottom-up
Tool overhead	Just git	Stacked-diff tool (stkd, Graphite, branchless)
Conflict surface	One PR’s conflicts with main	Conflicts can compound if mid-stack changes are large
Reverts	All-or-nothing	Surgical per-PR
Pair-programming fit	Excellent	Awkward — coordinate carefully
AI agent fit	Often produces unreviewable monster PRs	Encourages structured, small steps

Neither column is universally “better.” They’re matched to different problems.

What changes for the reviewer

A common worry: “if my teammate switches to stacks, won’t I get spammed with PRs?”

Reviewers actually win, for two reasons:

The total volume of code is the same, just split into smaller units that each take less time to read. You weren’t going to enjoy reviewing one 4,000-line PR. Four 1,000-line PRs are easier — and the next 1,000-line PR doesn’t appear in your queue until you’ve cleared the previous one.
The structure is self-documenting. Each PR in a stack has a focused scope. You don’t have to mentally separate “schema changes” from “OAuth wiring” from “UI” — the author already did that for you.

The thing that does change for reviewers is how the comments work. We’ve written a whole article on reviewing stacked PRs — the short version is: review them bottom-up, and don’t be afraid to land the bottom of the stack before the top is ready.

”Just use a feature branch with multiple commits” — why it’s not the same

The most common pushback on stacks is some variant of: “My feature branch already has multiple commits. Reviewers can read them one at a time. Same thing.”

It’s not. There are three concrete differences:

Each commit doesn’t get its own PR-level discussion. Inline comments are scoped to lines, not commits. The mental model of “approve commit A, request changes on commit B” doesn’t really exist in GitHub or GitLab’s UI — you approve or request changes on the PR.
You can’t land part of a feature branch. If the schema migration is done and approved, but you’re still working on the UI, the migration sits in PR limbo. With a stack, it can land today.
The author still has to wait. Even if reviewers handle each commit in order, the author can’t merge incrementally — so they’re back to “wait for the whole thing to land before starting the next thing.”

Multi-commit branches are better than one giant blob, but they’re not stacked diffs.

Mixed workflow with stkd

You don’t have to commit to one workflow per repo. stkd’s design specifically supports the hybrid: a branch only becomes “stacked” when you ask it to be.

# A normal feature branch — no stack involved
git checkout -b fix/typo
# … fix it, commit, push, open PR with `gh` or `glab` …

# A stacked change in the same repo, same day
gt create feature/auth-base
# … work, commit …
gt create feature/auth-oauth
# … work, commit …
gt submit --stack

The gt and git commands coexist; stkd never assumes a branch is part of a stack unless it was created or registered with gt.

A decision flow

When you start something new, ask yourself three questions:

Is this < 400 lines and will land in a day? → Feature branch.
Does this have at least two clear logical layers (e.g. schema → API → UI)? → Stack the layers.
Will I be blocked by review latency if I do this as one big PR? → Stack.

If you answer yes to (1), the rest doesn’t matter. If you answer yes to (2) or (3), use a stack.

That’s the whole heuristic.

Trying it

If you’re stack-curious, start small. Pick a single piece of work you’d normally do as one big PR, and try splitting it into two or three. Use stkd:

brew install neul-labs/tap/stkd
cd ~/code/your-repo
gt repo init
gt create feature/your-first-stack

After your second or third stack, the workflow clicks. After your tenth, you’ll wonder how you ever shipped 2,000-line PRs.