If you work in a team that stacks branches or uses Squash & Merge, you have almost certainly encountered this nightmare:

  1. You create branch feature-B off feature-A while waiting for review.
  2. feature-A gets approved and squash-merged into main.
  3. You open a Pull Request for feature-B against main.
  4. Disaster: Your PR suddenly includes all 20 commits from feature-A, hundreds of duplicate lines of diff, and a maze of merge conflicts.

A standard git rebase main often gets confused because the commit hashes of feature-A no longer exist on main (they were replaced by a single squash commit).

This is where Git's most underrated surgical tool comes in: git rebase --onto.

The Mental Model: Git as Scissors & Glue

A standard rebase says:

"Take everything on my branch since it diverged from main, and replay it on top of main."

The --onto flag gives you precision scissors:

"Take only the commits between point X and point Y, cut them out, and glue them onto point Z."

Syntax Breakdown 

 bash git rebase --onto <new-base> <old-base> [<branch>]