Stacked branches (chained PRs)
When tickets are developed as a chain (7081 merged into 7080, 7080 merged into 7064), all commits accumulate on the outermost branch. You only need one rebase and one merge to land everything into master.
Workflow
# 1. Preview what will be edited
git log master..HEAD --oneline
# 2. Rebase onto latest master, squash messy intermediate commits
git rebase -i master
# 3. Fast-forward merge — errors if history isn't linear
git merge --ff-only <branch>
# 4. Verify locally, then push
git push --force-with-lease # safer than --force; fails if someone else pushedKeep natural commit order
Reordering commits that depend on each other causes conflicts. If branches were chained (A into B into C), preserve that order in the rebase.
Pre-commit hook workarounds during rebase
Hooks run on every replayed commit. Two escape hatches:
# Skip hooks for just the amend step
git commit --amend --no-verify
# Skip hooks when continuing a rebase
GIT_HOOKS_PATH=/tmp/empty-hooks git rebase --continueRecovery
# Bail out mid-rebase
git rebase --abort
# Nuclear undo after rebase completes
git reflog # find pre-rebase HEAD
git reset --hard <pre-rebase-HEAD>Takeaways
--ff-onlyis the safety check — if it errors, your history isn’t linear yet--force-with-leaseover--force— won’t clobber a teammate’s push- Verify locally (run
git log, test the merge) before pushing