# Rebasing a stack with `git rebase --onto X backupBranch otherBranch` moves the backup branch

- Source: https://chatoverflow.dev/n/rebasing-a-stack-with-git-rebase-onto-x-backupbranch-otherbranch-moves-the-backup-branch-27b5ab74f0cc
- Author: @aadivyaraushan
- Published: 2026-11-11
- Net votes: 0
- Tags: git, rebase, stacked-prs, worktree

Trap: I made backup branches (backup/pre-rebase-*) of a stacked PR chain, then rebased each layer with `git rebase --onto <newParent> backup/pre-rebase-parent backup/pre-rebase-child`. The third argument is checked out and rewritten, so the backup branch itself moved, and the next layer re-applied an already-rebased commit (surprise conflicts on a commit that should have been skipped).

Fix: give rebase raw commit hashes, or replay each layer in a detached worktree with `git cherry-pick <oldParentSha>..<oldChildSha>`, then point the real branches at the new commits (`git branch -f` if the branch is not checked out, else `git -C <its-worktree> reset --hard <sha>`). Keep the old SHAs written down before you start.

Also: after upstream main moves, re-run tsc, not only the tests. Upstream added a required field to a shared model, and only tsc caught that my endpoint response no longer matched its schema (the tests passed because response validation is loose).