Your git history is important

People underestimate the importance of keeping a tidy git history. A clean git log can be an invaluable tool for tracking the state of a project over time.

Commit often, rebase later

When I first started using git, I didn’t give much thought to the kind of history I was leaving behind which meant commit logs like this:

My process was “do a bunch of work,” “one giant commit,” “leave a crap log message.” You might say that’s OK if you’re just working by yourself, but I think there’s benefit to staying organized regardless of whether or not you’re solo or on a team. It’s important, even for yourself, to be able to retrace steps to see what was done and why.

That’s why I adopted the strategy of “do a little work,” “commit,” “do a little more,” “commit,” “repeat,” “git rebase to cleanup history.” The basic idea of git rebase is that it lets you rewrite history by re-ordering commits or combining multiple commits into a single one.

(Check out this great Atlassian tutorial if you’re not familiar with git rebase.)

Git Rebase Basics

Let’s look at a contrived example:

In the above, I created a PHP class called MyClass and added it to git. Then I realized I’d committed an empty file so I went back and added the class definition. Then I realized I didn’t add a class constructor so I did third commit to add it.

There isn’t a lot of value in having those three separate commits because it’s all part of adding the MyClass class. What I really want is a single commit that encompasses all of that work.

And the way to do that is an interactive git rebase (git rebase -i) which pops up an edit window that looks like this:

(You’ll also notice a bunch of comments showing the available rebase commands. We’re just going to focus on fixup and squash for now.)

If we don’t change anything, save and exit, our commit history will be unchanged since we chose to “pick” each individual commit.

What we really want to do is edit the rebase to look like this:

Each line that starts with fixup will squash that change into the change before it and throw away the log message (squash is the same as fixup but the log message for each commit is preserved and combined).

After the rebase, our history looks like this:

Now we have one commit that contains all three of the changes we made above.

Easier rebasing with autosquash

That’s the basics of rewriting history with git rebase, but there’s an even easier way to do in Git 2.7 and it’s called autosquashing.

Let’s say I’m going to work on a new method for MyClass and I’m going to make a bunch of small commits and clean them up when I’m done.

My first commit looks like this:

Now I’m going to make another change but instead of just doing a normal git commit, I’m going to do

git commit -a —fixup :/^Added.

Let’s break down what that’s doing

• git commit -a
  • commit all changes
• --fixup
  • do a Fixup Commit – basically the word “fixup!” is prepended to the log message (you can also use --squash)
• :/^Added
  • we’re fixing-up the first commit with a log message that starts with the word “Added” (you can also specify a commit SHA)

After the fixup commit, our log looks like this:

And here’s the fun part. When we do a git rebase -i --autosquash we end up with this rebase screen:

Notice how the fixup command has been automatically added for us? The same would be true of squash! commits.

The autosquash feature works for as many commits you have in the rebase that are tagged with fixup! or squash! and it will even reorder commits if you have multiple fix-ups happening on different commits in the rebase.

(See Auto-squashing Git Commits for more detail.)

So keep your git history tidy. Your teammates and your future-self will thank you for it.