Git has been a tool that I have constantly been using throughout my career and in my opinion is a skill that every developer should master. My personal preference for finding my way around things is using the CLI instead of an app that provides a GUI. In this blog post we’re going to get a bit more familiar with git rebase and see how we can use it to squash, reorder and rename commits.
You might be wondering why do we even need to do that. When we open a Pull Request on Github, it will give us an option at the end to squash and merge. why would we need to do that manually? I also had the same question until recently a colleague pointed out to me how he personally looks at commits when reviewing code.
He gave me a few examples of why having a clean git history with messages grouped by domain helps a lot with reviewing. If we do that, we won’t have to squash and merge our PR which will give us more commits related to specific changes. If we identify an issue, that will make it easier to revert smaller pieces of code instead of a commit that refers to entire PR.
We want our commit history to tell a story of everything that happened to the codebase until that point. If you’re getting stressed when your commits looks like the following, then that blog post is for you.
Let’s learn how we can squash commits. We can use the git rebase command which provides with plenty of options for rewriting history. First let’s run git log which will show us the following.
There are many things that are wrong here so let’s take things one step at a time. First one that I see is that we have 2 commits related to the readme file. Let’s squash them into one.