Red Green Repeat Adventures of a Spec Driven Junkie

Ways I Rebase

Before making a pull request, like to the master branch, I prefer to have a single commit of instead of multiple commits.

Green Sand Beach, Big Island, Hawaii

(This article isn’t about WHY you should have only a single commit when making a pull request, but about how to do it more efficiently. If you do make single commits, you definitely score more points in my books!)

Interactive Rebase

One way to have a single commit: perform an interactive rebase with command to squash down commits:

$ git rebase -i HEAD~N

(where N is the number of commits different from the master branch)

This is easy, but honestly, I have got lost doing this because of all the commits.

Github to the rescue

A clever trick I used was to start the pull request on github and use it’s commit count as a way to have it calculate the N value for me, so I would make the PR, then see the count, and use the previous technique to create a single commit.

git Mastery

Well, even without Github, there’s a better way to squash all the commits down from

$ git rebase -i master

This automatically takes all the commits in the current branch that are different from master and prepares the for an interactive rebase, where you can squash, reorder, or discard them.

No need to count!

Nifty, isn’t it?