kata-stacked-pr-merge

Merging stacked pull requests in order requires processing the bottom layer first, then sequentially updating each upper layer's GitHub base to main, rebasing onto origin/main, and force-push with lease before merging. This preserves correct branch bases throughout the stack.

Rebasing stacked PRs onto main involves explicitly changing each upper PR's GitHub base to main before performing a local git rebase onto origin/main. A force-push with lease updates the remote branch safely without overwriting concurrent changes.

Yes, the stacked PR merge process validates CI status, approval presence, and mergeability for each layer before merging. It also checks umbrella issue closure to ensure full stack completion and stops when conflicts arise.

Yes, the stacked PR merge workflow supports a git-spice variant for syncing and rebasing layers after merges. It also provides a vanilla gh plus git workflow path for teams not using git-spice.

When a rebase conflict occurs during a stacked PR merge, the process stops and delegates conflict resolution to the rebase kata. This prevents out-of-order merges, premature branch deletion, and broken upper layers.