Posted almost 2 years ago. Visible to the public. Linked content.

Git: rebase dependent feature branch after squash

This card will show you how to use git rebase --onto without confusion.

Use case:

You've got two feature branches (one and two), where two depends on one. After code review the commits of branch one are squashed. Thus the commit history this branch has changed. Branch two however didn't change. To make the branches share the same commit history again you will have to rebase and replay the additional commits of branch two onto branch one.


The easiest way for me to correctly use git rebase --onto is to count the number of additional commits of branch two and use the following command:

git rebase --onto one HEAD~<commit_count>

Make sure you are on branch two while executing this command.


Say one looks like:

O - A - B - C

two has a few extra commits on top of that:

O - A - B - C - D - E - F

You squash feature branch one down, giving you:

O - S

Now, when you try to rebase the dependent branch two, git is going to try to figure out the common ancestor between those branches. While it originally would have been C, if you had not squashed the commits down, git instead finds O as the common ancestor. As a result, git is trying to replay A, B, and C which are already contained in S, and you're going to get a bunch of conflicts.

For this reason, you can't really rely on a typical rebase command, and you have to be more explicit about it by supplying the –onto parameter:

git rebase --onto one HEAD~3 # instruct git to replay only the last # 3 commits, D E and F, onto one.

Modify the HEAD~3 parameter as necessary for your branches, and you shouldn't have to deal with any redundant conflict resolution.

Some alternate syntax, if you don't like specifying ranges and you still have a commit pointing to the unsquashed branch one (one_unsquashed):

git rebase --onto one one_unsquashed two # replay all commits, starting at one_unsquashed # exclusive, through two inclusive # onto one (squashed)

You might want to consider creating a branch like one_unsquashed anytime before squashing it down if there are dependent branches and you want to use this syntax.

By refactoring problematic code and creating automated tests, makandra can vastly improve the maintainability of your Rails application.

Owner of this card:

Daniel Straßner
Last edit:
almost 2 years ago
by Daniel Straßner
About this deck:
We are makandra and do test-driven, agile Ruby on Rails software development.
License for source code
Posted by Daniel Straßner to makandra dev
This website uses cookies to improve usability and analyze traffic.
Accept or learn more