When Interactive Rebase Isn't Enough
Most developers know git rebase -i for cleaning up commit history. But there's a scenario that trips up even senior engineers in interviews: what happens when you need to move a feature branch from one base to another, and the original base has commits you explicitly don't want?
git rebase --onto solves this. It's the surgical tool for branch transplants, and understanding it separates people who've shipped messy production fixes from those who've only worked in pristine feature-branch workflows.
Here's the syntax that makes people's eyes glaze over:
git rebase --onto <new-base> <old-base> <branch>
The mental model: take the commits after <old-base> on <branch>, and replay them on top of <new-base>. The <old-base> parameter is what throws people off — it's not where the branch currently points, it's the exclusion boundary. Everything after that commit gets moved.
I'm going to walk through four scenarios where --onto is the only clean solution. Each one is based on interview questions I've seen at companies like Stripe and Databricks, where Git fluency is a signal of production experience.
Continue reading the full article on TildAlice
Top comments (0)