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
Submit the current Graphite stack to the remote and open or update pull requests. User input: $ARGUMENTS.
gt submit pushes the current branch and everything downstack from it.gt submit --stack (alias gt ss) pushes the entire stack rooted at trunk.gt submit --stack --update-only (gt ss -u) updates PRs only — won't open new ones.If the user didn't specify scope and the stack has more than one branch, ask whether they want --stack or just the current branch + downstack.
gt ls and show the user which branches will be submitted.git status --short to confirm there are no uncommitted changes. If there are, ask whether to gt modify -a them in first, stash, or abort.gt sync --no-pull or gt restack if gt ls shows any branch as needs restack — do not submit a stale stack.gt submit command. Pass -c / --confirm to skip interactive prompts only if the user asked for non-interactive.--stack — submit every branch in the stack (not just current + downstack)--update-only, -u — update existing PRs, never create new ones--draft — open as draft-c, --confirm — skip the interactive prompts-e, --edit — open $EDITOR for each PR description-f, --force — force-push (use with care; Graphite already uses --force-with-lease by default)--ai — Graphite drafts the PR title/body