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.

Solution:

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:

Copy
git rebase --onto one HEAD~<commit_count>

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

Example:

Say one looks like:

Copy
O - A - B - C 

two has a few extra commits on top of that:

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

You squash feature branch one down, giving you:

Copy
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:

Copy
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):

Copy
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.

Check out our new e-book:

Growing Rails Applications in Practice

Learn to structure large Ruby on Rails codebases with the tools you already know and love.

Learn more