Stacked pull requests — when the workflow is worth adopting

The problem being solved

One feature can produce a pull request over a thousand lines. No reviewer can find the time, so it sits for two days. Meanwhile the next task has to be started on top of an unmerged branch, and every later correction gets harder.

Stacking turns that thousand-line PR into five of two hundred lines, each based on the one before. Reviewers can engage with two hundred lines, merging proceeds from the bottom, and the bases of the PRs above follow automatically.

What Graphite actually sells

Stacking itself needs nothing but Git: chain the branches and rebase the ones above when a lower one changes. What Graphite sells is doing that rebase chain automatically and giving you a view of the stack.

When it is worth adopting

• Pull requests routinely exceed a few hundred lines
• Work stalls waiting for review several times a week
• Reviewers are scarce, so PRs wait before anyone starts
• Everyone on the team is comfortable with Git branching

The fourth is a precondition, not a nice-to-have. Stacking makes Git operations one step more complex, and a team member who does not understand what rebase does will eventually destroy history while resolving a conflict. Budget time to go over rebase behaviour before adopting.

When it will not help

• PRs are already small (100 lines is normal) → there is no problem to solve
• Reviews come back within hours → there is no waiting problem
• Solo development → nothing waits on review, though small PRs are still a good habit
• Squash merge is mandatory → stacked history needs additional design

The third deserves a note: even alone, keeping PRs small has value. Tracing a change later is easier across five 200-line PRs than one of a thousand. Whether you adopt the tool is separate from whether you adopt the habit.

How to split a change

The benefit depends entirely on where you cut. Splitting mechanically by line count produces intermediate PRs that do not build, which cannot be reviewed. Split like this instead.

• 1. Add types and interfaces — existing behaviour unchanged
• 2. Add the implementation — not yet called
• 3. Switch existing code to call it
• 4. Delete the old implementation

Each of those builds and passes tests on its own. 'Could this merge independently?' is the test of whether the split is correct.

Frequently asked questions