We all do it, and I’m sure that you do too. You know, the rapid commits when you are testing something, then fixing a typo, then commit again, push, test and on and on.
I usually do it when I’m working on deployment or build code, positive that it’s just a tiny fix, one little modification and that’s it. So I commit with a meaningless message, push test and, see an error. Let’s call it BDD: Brute-Force Driven Development.
Now I’m left with a branch full of, well, embarrassing commits that are heading straight to a pull request and code review.
However, I do have a little trick up my sleeve that helps me push those changes like that 10x engineer on my team.
Use git squash. Other than looking smarter, you can keep the history of the branch cleaner and much more readable for others.
Squashing commits can be done in a few ways, where your end goal is to rewrite the commit history and leave just one commit instead of multiple meaningless ones. You can choose to leave the commit message history or rewrite that as well, so it’s another opportunity to communicate the changes you introduce.
git log - before
The best way to understand git squash is to look at the git log. In this example, I have a feature branch that has three commits.
* 510b129 (HEAD -> docker-rmi) missing flag * cd62deb typo #2 * dba34d5 typo * 46e95a5 Listing local docker images * e30e77d (master) Starting the build process * 9409666 Adding the build script
git log after
After performing a “squash”, the git log looks like this:
* 617c65c (HEAD -> docker-rmi) Listing all the local docker images * 46e95a5 Listing local docker images * e30e77d (master) Starting the build process * 9409666 Adding the build script
It’s like we went back in time!
You can see that instead of all the “typo” commit messages and the missing flag, we now have just one commit message that includes all of the changes we made.
There are a few ways to squash commits, and I’ll show you two that cover different use cases. There is a wonderful thread on StackOverflow if you want to see more methods.
Squash on the same branch
When you want to alter the branch history, squashing a few commits back, the
git reset --soft command can come in handy.
WARNING - Make sure you don’t have uncommitted changes. Either commit or stash them before performing the reset command.
If you want to squash your last three commits run the command:
git reset --soft HEAD~3 && git commit
git reset --soft 46e95a5 && git commit
To push your changes, you have to use the –force flag, as you altered the branch history.
git push --force
Again, for more, see the link above to the StackOverflow thread.
Squash on merge
If you are a confident person and just want to keep the master (or any other) branch clean, you can use the
git merge --squash command. Most of the pull request UIs allow you squash merge as well.
git checkout master git merge --squash featurebranch
By default, the commit includes all the original messages but, you can rewrite it as well. Your original branch keeps the original history, so that you can reference it.
Do this now
Like everything Git, knowing about the method adds another tool to your belt. But then again, there is always this “fear” of running commands for the first time on your existing codebase. So go ahead and create a clean git repo and try these methods out in a safe environment. Your hand will be less likely to shake once you see how it works on your own.