Why You Should Care About Squash and Merge in Git

Make your history more clean and readable

We just develop our new feature in Kurio. It is a targeted push notification. More about this you could read it here

We have a “good” enough development life here. When it was decided to create a new feature, a mini team will be assigned to their role. The team can consist of a few people from the different division, 2 from backend division, 1 from machine-learning division and so on based on the project needs.

We use Github as our project repository to all company’s project, so it eases us to collaborate between different divisions.

The project we just develop done for 3 weeks.

Review and Pull Request

Github now has the feature review on its Pull Request (PR). So with this feature we can do discussion about the feature that will develop, every single code was reviewed by each member in teams.

Create a Pull Request When we ready, we create a pull request, so every team can review the PR. Thanks to Github :XD

Too many commit may mess your git history

One of the feature git, is enabled us to record all changes by commit. And saved it as our history. So when something unexpected happen, you can rollback to specific commits.

commit up to 79 But sometimes, with this feature of git, we can come with too many commits on a single PR (pull request). This also can make our history not clean for developing a single feature. So, when unexpectedly happens in production, we will hard to find the specific commit for rollback.

In our latest project, when developing new feature targeted push notification, we make a lot of commit for this single feature. It’s up to 79 commits. And some of the commits literally just like testing commits.

Unimportant commit to be recorded Imagine this commit will merged to master’s branch, and we see this history. This history maybe a little readable, because the message is clear when doing commit.

What about this one:

Please don’t laugh on me :D

What if your commit will look like that. This is totally destroy your git history. May be you can force your team to use the proper message, or maybe you have a rule, only do commit when you make a huge changes. But maybe, I’m at your team, and doing this. I know it’s not good. Totally not ver very good. But, there is always a person like me in your team. Alwaysss!! 😈

Introducing Squah and Merge

Luckily, git already handle this. In github, this feature already added and can configurable trough the project setting.

With the squash and merge feature, your PR will merge into one single commit. And with this, your history will be full of unimportant commit.

git merge . taken from https://github.com/blog/2141-squash-your-commits This how your commit and history if using a normal merge. Your history from your feature branch also will wrote in the master branch.

So to clean this, you could use the squash option.

git squash and merge. taken from https://github.com/blog/2141-squash-your-commits With this, your commit history will merge into new one commit, and merge it into master.

With github, this already handled. You just only to allow the squash and merge from the project option.

allow the squash and merge Or you can prevent the unexpected merge, by just allow squash and merge. And when merging the new PR, you only just choose the squash and merge option

Squash and merge And now all your commits will merge into one single commit.

Commit history See, our commit history more cleaner, and only grouped by a single feature or a single fixing.


Nowadays, there are a lot tools to help us to increase our productivity. For example this feature by git, which is used by github. Clean your git history now and increase your productivity.

Previously posted in: https://blog.pairworking.com/why-you-should-care-about-squash-and-merge-in-git-675856bf66b0

Share Comments
comments powered by Disqus