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 pushed

Keep 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 --continue

Recovery

# 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-only is the safety check — if it errors, your history isn’t linear yet
  • --force-with-lease over --force — won’t clobber a teammate’s push
  • Verify locally (run git log, test the merge) before pushing