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
Sync the local repository with origin. gt sync pulls trunk, prompts to delete branches that have been merged into trunk, and restacks the remaining stack onto the new trunk tip. User input: $ARGUMENTS.
git status --short to ensure the working tree is clean. If not, ask whether to commit/stash before syncing.gt ls to capture the stack shape before sync.gt sync $ARGUMENTS (respecting any flags the user passed).gt co <branch> → gt restack → resolve in editor → gt add . → gt continue -a.gt abort and report.gt ls again so the user sees the new state and which merged branches were pruned.-a, --all — sync every trunk (when multiple trunks are configured)-d, --delete-all — delete merged branches without prompting-f, --force — accept all destructive promptsgit pullAlways prefer gt sync in a Graphite-tracked repo. Plain git pull won't restack downstream branches and can leave stacks pointing at the old trunk tip, which then requires a manual gt restack.