It happens to everyone: you start feature-b from feature-a because you needed its changes, and then feature-a merges - squash-merged, naturally, so its commits on main have different hashes. Now your pull request for feature-b shows ten commits instead of three, half of them already on main. Or worse, feature-a gets abandoned, and your work is sitting on a branch going nowhere.
git rebase --onto is the precise tool for both. It says: take my commits from here to here, and replay them over there.
The recipe#
git rebase --onto main feature-a feature-b
Read it as: take everything on feature-b that is not on feature-a, and replay it onto main. Your three commits land on top of main, the squash-merged duplicates vanish from your branch, and the pull request shrinks to what you actually wrote.
The abandoned-branch case is identical: if feature-a is dead, the same command moves feature-b onto main without dragging the dead work along.
After the move#
Your branch was rewritten, so the push needs the safe force:
git push --force-with-lease
That is the whole workflow - the force-with-lease guide covers why the flag matters. If the rebase hits conflicts, resolve them the same way as any merge conflict; Git stops at each conflicting commit and lets you continue with git rebase --continue.
Preventing the tangle#
Stacking branches is sometimes unavoidable, but two habits make it rare:
- Branch from main by default. Before
git switch -c, glance at where you are. Half of all wrong-base branches are born in a hurry. - Prefer small pull requests. A PR that merges in a day is rarely something you need to build on top of; a PR that sits for two weeks practically forces stacking.
And when stacking is genuinely needed - a big feature split into dependent slices - note the dependency in the pull request description, so nobody merges the second slice first.
rebase —onto looks intimidating in the manual and is three words in practice. Learn it once and the wrong-branch mistake stops costing an afternoon.
Share this post
Keep reading
Annotating Commits with git notes: Metadata Without Rewriting History
Some things belong on a commit but not in it: review links, benchmark results, the ticket nobody remembered to reference. git notes adds them after the fact, no rebase required.
Backing Up Your Git Server So It Actually Restores
Every clone is a partial backup - but hooks, config and server state live outside the repo. Mirror, bundle, copy off-site, and rehearse the restore.
Cherry-Picking: One Commit Without the Branch
Cherry-pick copies a single commit onto your branch and leaves the rest behind. Right for hotfixes across release branches, wrong as a sync strategy.
