This is the team-level follow-up to Graphite. The CLI is easy; changing how fifty people open pull requests is the hard part.

Why do team Graphite rollouts fail?

Two reasons. First, mixed tooling. If half the team pushes with gt submit and half uses raw git push, the stack metadata goes stale and someone force-pushes over a branch.

Second, the merge queue. It is genuinely useful at scale, but turning it on during a workflow change means two new things break at once, and nobody can tell which one caused a bad merge.

What should the pilot squad do first?

Give one team of three to five engineers the CLI and nothing else. No dashboard, no merge queue. Their only job for two weeks is to create one stack per feature. Measure two things:

• Median time from first commit to merge.
• Number of stacks left open longer than three days.

If merge time drops and stale stacks stay rare, the workflow fits. If stale stacks pile up, the problem is process, not the tool, and a wider rollout will not fix it.

When should you enable the merge queue?

After the pilot, and only if your CI takes longer than about ten minutes. Below that, serialized merging is fast enough and the queue adds a step with little benefit. Above it, the queue pays off because it tests a batch of PRs together instead of one at a time.

Roll it out behind a flag on a single repo first. Watch for CI failures that only appear in the queue — batched runs surface flaky tests that individual PRs hide.

How do you handle trunk changes across many stacks?

Set one rule: everyone runs gt sync at the start of the day, before creating new branches. This keeps stacks close to trunk and avoids the multi-branch conflict cascade.

For repos with heavy trunk traffic, add a convention that stacks stay under five PRs. Long stacks magnify every rebase, and a five-layer stack left overnight is where teams get burned.

What changes in code review culture?

Reviewers stop ignoring the big PR — there is no big PR. The flip side is more pull requests to triage, so you need at least one reviewer who watches the stack and merges layers as they clear. Pick that person explicitly, or stacks rot at the top.

Quick Summary

• Pilot stacks with one squad for two weeks before a team-wide rollout.
• Require everyone to use gt submit; mixed tooling corrupts stack metadata.
• Enable the merge queue only if CI exceeds roughly ten minutes.
• Run gt sync daily and keep stacks under five PRs.
• Assign one reviewer to shepherd and merge each stack top-down.

It targets teams where a single 1,200-line pull request sits unreviewed for three days. Stacks of three 200-line PRs move faster because each one is trivial to approve.

How do you install the Graphite CLI?

Three steps, then you are working:

1. Install the CLI: npm install -g @withgraphite/graphite-cli.
2. Run gt auth and connect your GitHub account.
3. In a repo, run gt init and pick your trunk branch — usually main.

From there, gt create makes a branch, gt submit pushes the whole stack and opens or updates the PRs, and gt sync pulls trunk changes down through every branch in the stack.

What does building a stack actually look like?

Say you are adding a settings page. Instead of one branch, you layer it:

• gt create settings-backend — the API endpoint, nothing else.
• gt create settings-ui — the form, built on the backend branch.
• gt create settings-tests — tests covering both layers.

Now gt submit opens three PRs, each targeting the one below it. A reviewer can approve the backend while you are still writing the tests. That parallelism is the whole point.

Is Graphite free?

The CLI is free and open source, and you can use stacks with plain GitHub. Paid plans add a web dashboard, merge queue, and team analytics. A solo developer or small team gets the core workflow at no cost — the paid tier is about visibility across many stacks and people.

What breaks in a stacked workflow?

Rebasing, mostly. When trunk moves, every branch in the stack needs updating, and a conflict anywhere can cascade. gt sync handles the routine case well, but a conflict in the lowest branch forces you to resolve it once and re-sync upward — do not resolve the same conflict three times.

The other trap is stale stacks. A stack left open for a week turns into a rebase marathon. Keep stacks short and merge top-down as soon as each layer is approved.

Quick Summary

• Graphite splits large changes into stacked, dependent pull requests.
• Install via npm, then use gt create, gt submit and gt sync.
• The CLI is free; dashboards and merge queues are paid.
• Rebasing conflicts cascade — resolve once in the lowest branch.
• Merge stacks quickly; a week-old stack is a rebase marathon.

For automated review comments on each PR in the stack, CodeAnt AI layers on cleanly.