Git provides some excellent features when you need to amend your commit history before pushing your changes into a repository. In today’s article, I’ll run through a relativly simple use-case of the rebase command and how you can squash commits down.
This blog
I’ve recently changed text editors from Sublime back to vim. In the repository of this blog, I have a script that bootstraps a blog post with the title and date; and then opens my text editor ready for me to write.
Today I also patched a small bug where, when the file name is calculated from the title of the blog I specify - consecutive letters were being de-duplicated. Made it a real pain for a lot of words . . so, this changed. These two changes occured on the same file, new-post.sh; but I didn’t think about changing my text editor until after.
The first change
So, the first change went into the file. I staged the change and then committed it:
The second change
Then, thinking about it, I changed my text editor after.
This sucks. Really only wanted this in the one commit. So, I kicked off rebase in interactive mode (with -i).
This opened up a text editor for me, allowing me to make changes.
Changing history!
You’re presented with a list of commits that haven’t yet been pushed to the server. You’re also given the opportunity to change what goes on with these before you push:
I just want 7408fdf squashed into 5b7b3b4. I also want to change the commit message of 5b7b3b4. Afterwards, I’d learned that git will give me the opportunity to re-word this to combine commit messages.
Saving this file off, we’re now presented with another text editor that allows us to update the commit message accordingly. After a bit of processing, we’re done:
Your git log should now confirm that everything has gone to plan: