My team has recently been experimenting with a squash and merge strategy on our pull requests, and I took the opportunity to up my git skills so I could avoid a frequent rebasing issue.

It can be common to work a couple of feature branches away from the main branch.

A--B main
    \
     C--D feature-1
         \
          E--F feature-2

While feature-1 is up for review and feedback is being addressed, I’ll move on to the next feature-2 branch which depends on feature-1 commits.

Eventually, feature-1 is squashed and merged into main as a new, single commit. When I’m preparing feature-2 for a pull request, I was running…

git rebase main

…but then I’d have to slog through the merge conflicts of the feature-1 commits on my feature-2 branch.

I learned I should be using --onto with an additional branch parameter to customize where in history I want to start replaying commits.

git rebase --onto main feature-1

Translation:

Take all the commits on my current branch since feature-1, and play them back on top of main.