Stacked PR workflow with the Graphite CLI (gt) — create stacks, submit, sync, restack, split/squash/fold, track existing branches, collaborate on shared stacks, configure repo/CI for Graphite, and operate the merge queue.
70
88%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
When the working tree contains hunks that logically belong to several different downstack branches, gt absorb figures out which branch each hunk should amend into and applies them. User input: $ARGUMENTS.
/graphite:modify instead — it's simpler.git status --short so the user sees the working-tree state.gt ls to show which branches are candidates downstack.gt absorb -a -d (or gt absorb -p -d for hunk selection). Show the user the proposed branch-per-hunk assignment.-d to apply. Each affected branch is amended, then everything upstack is auto-restacked.gt add . → gt continue -a, or gt abort.gt ls and consider gt submit --stack -u to update PRs.-a, --all — consider all modified files (default is staged only)-p, --patch — interactive hunk selection-d, --dry-run — show the plan without amending