Rebasing Onto A Squashed Commit April 23, 2018 | Ellen Shapiro

When you're using Github's nice "Squash and Merge" button (or the GitLab equivalent, or git merge --squash) to squash all the commits in a pull request rather than simply merging them, your commit history can get really screwy if you try to rebase off of the merged commit.

Let's say I have master branch, that I make branch fix. off of to fix some small bugs. I make commits m, n, and o on that branch. Then from o, I create branch feature, and make commits p, q, and r, that implement some new feature that depends on the previous fix. Visually, it'd look something like this:

        | (branch feature)
        | commit r
        | commit q
        | commit p
       /
      /
     /
     | (branch fix)
     | commit o
     | commit n
     | commit m
    /
   /
  /
-/
|
(master)

Next, I'd make a PR from branch fix into master:

          | (branch feature)
          | commit r
          | commit q
 PR       | commit p
  \      /
   \    /
    \ /
     | (branch fix)
     | commit o
     | commit n
     | commit m
    /
   /
  /
-/
|
(master)

Once that PR is merged, you wind up with something which looks something like this:

 | (branch feature)
 | commit r
 | commit q
 | commit p
 | commit o
 | commit n
 | commit m
 \
  \     (master)
   \   / including the squashed commits of `fix` branch: m, n, and o
    \-/
     |
     |
  (master~1)

If I merge branch feature into master right now (without squashing), while the file changes will be correct, suddenly the previously squashed commits of the fix branch will show up again in the master branch history. This is unfortunate, as I wanted to get rid of those.

Alternatively, if I merge branch feature with squashing, the commit messages of the squashed commits of the fix branch will be included in the commit message of the squashed commit in master. While I can remove that manually, it's a hassle and error-prone.

If I try to do a vanilla rebase before the merge, rebase will attempt to apply the changes from every single commit - including commits m, n, and o, which have already been squashed and merged.

This is because the metadata about the individual commits that made up the squashed merge are gone. In fact, this is the only difference between a squashed merge and a normal merge: Both put the merged commits on top of the destination branch, but while a normal merge does this in a special merge commit that includes metadata about the commit hashes of the branches that have been merged, a squash merge omits that metadata, and "pretends" the merge commit is a normal commit.

Now, if you've got a branch which you created off of the commits which were squashed and merged, using a plain vanilla rebase command will attempt to apply every one of those commits again, sequentially.

This gets annoying very quickly. I asked in our Slack if anyone knew a good way around this. A few people banged their heads together, and we wound up with an answer that takes the commits at the end of branch feature, which haven't been merged yet, and make them do something like this:

 | PR
 |
 | (branch feature)
 | commit r
 | commit q
 | commit p
 \
  \
   \
    \-
     |
     |
  (master) including squashed commits of `fix` branch

There's a slightly obscure git rebase sub-command for this. git checkout the branch you want to pick a bunch of commits off of and plop them onto master. Then, you can pass in the magic commands:

git rebase --onto master [hash for commit o] [hash for commit r]

What this does is tell Git that it should rebase a range of commits on to master. Note that you actually need to start with the commit before those you wish to pick up and move over onto master, so that all the commits are picked up.

One thing to note is that this exact command will cause the result to appear as a detached HEAD rather than as HEAD of the branch you have checked out. You'll need to create an updated branch from there, as your original feature branch will still be as it was (which is slightly annoying, but VERY helpful if you mess this up). Alternatively, you can checkout feature again, and reset --hard that branch to the hash of the detached head.

Now, you're able to make a PR that looks like the most recent ASCII art above, and have a clean commit history while still taking advantage of branching, squashing, and merging.