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.
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.
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.
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:
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.
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: