Why You Should Care About Squash and Merge in Git

We just develop our new feature in Kurio. It is a targeted push notification. More about this you could read it here: Developing Backend for : Targeted Push NotificationStory of how we develop the targeted push notification service from backend-side at Kurio.hackernoon.com

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 the 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 a 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 commits may mess your git history

One of the feature git, is enabled us to record all changes by a commit. And saved it as our history. So when something unexpected happens, 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 a 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 be 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 😀

What if your commit will look like that. This totally destroys your git history. Maybe you can force your team to use the proper message, or maybe you have a rule, only do commit when you make a huge change. 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. Always!! 😈

Introducing Squash 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.

Conclusions

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.

More about this at github: