Squashing Git commits

Let’s talk about squashing commits in Git.

In projects where I’m the only developer, which means all my personal projects, I do tend to work on the main branch when I can. For example if I’m doing a simple change, or adding a new post to the blog. Fast and non-breaking stuff.

In some cases however I do not use this approach, and instead I create a branch for a big feature.

This is also the default when working on a team-based or open source project.

You create a branch, and commit often. Committing early and often is a great advantage because you can work on your code with the confidence that you can always return back to a working state, or at least to a state you know that something worked.

You might do a series of quick commits where the message is “ok”, “trying this”, or “fix dumb mistake”.

But at some point you need to converge to a stable state and commit the changes back to main, or to any branch you want.

You want to do one thing before that: squashing your commits.

GitHub can do that for you automatically when you are merging a Pull Request, and it’s a workflow I’ve been using a lot on public Open Source repositories in the past.

Instead of seeing all the individual commits contained in a Pull Request, you only see one commit, and in the PR merge process you can write a detailed and dedicated commit message and description.

This will eliminate all the previous Git commits that diverge from the head of the branch you’re merging to, and also remove all those commits where maybe you reverted changes, and so on.