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
Create a new Graphite-tracked branch on top of the current branch, carrying the working-tree changes as a single commit. User input: $ARGUMENTS.
git status --short to confirm there are changes to commit. If the tree is clean, ask the user whether they meant to run gt create --onto <branch> (create empty branch on top of another).gt ls to show the current stack so the user can confirm where the new branch lands.$ARGUMENTS looks like a commit message (contains spaces or :), use gt create -am "$ARGUMENTS" — Graphite derives the branch name from the message.$ARGUMENTS is a single token, treat it as a branch name. Ask the user for a commit message, then run: gt create -am "<message>" $ARGUMENTS.$ARGUMENTS is empty, ask the user for a commit message (or branch name) before proceeding.gt ls.-a, --all — stage every modified file (default for this command)-m, --message <msg> — commit message (and source of the auto-generated branch name)-p, --patch — interactive hunk staging instead of -a--insert — insert this branch between the current branch and its children, restacking dependents--onto <branch> — create on top of a different branch (useful with worktrees)--ai — let Graphite suggest a branch name / message