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

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.

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.

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.

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:

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.

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.

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.

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

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

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: https://github.com/blog/2141-squash-your-commits

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