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

) 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

branch, that I make branch . off of to fix some small bugs. I make commits , , and on that branch. Then from , I create branch , and make commits , , and , 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

into :

          | (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

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

Alternatively, if I merge branch

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

If I try to do a vanilla

before the merge, will attempt to apply the changes from every single commit - including commits , , and , 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

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

, 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

sub-command for this. 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:

What this does is tell Git that it should rebase a range of commits on to

. 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

rather than as of the branch you have checked out. You'll need to create an updated branch from there, as your original branch will still be as it was (which is slightly annoying, but VERY helpful if you mess this up). Alternatively, you can checkout again, and 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.