See in this article some good practices that you can use when pushing your commits.
This post idea is to be something quick and clear that can help you when sending your commits.
To start, I would like to ask you two questions:
-> In the last few days, have you or any member of your team sent a commit similar to: “uploading the latest version of the code”, or “now it’s time” or did you simply send “m”?
-> Have you ever needed to analyze the history of your last commits and had to go in one by one because you weren’t able to understand the purpose of each of the commits?
If you answered yes to one of these questions, you and your team need to improve the standard of your commits and to help you, I’m writing this quick post.
First, your commits need to answer the following questions:
-> Why is this change necessary? It can fix a bug, add a feature, or improve performance or security.
-> How does it solve the problem? For small or obvious changes this part can be omitted. It is a high-level description of the approach used to address the given problem.
What effects do these changes have? In addition to the obvious ones, this can include benchmarks, side effects, etc.
After answering the questions above, you can use the best practices for creating semantic commits. Below you have some of them with a brief description:
Feat: We use it when we are going to create a new feature in the project. Eg: we are creating a new endpoint in an API, or we are adding a new service within our project.
Refactor: Although the name is suggestive, it is important to reinforce its importance. We use refactor when we are updating some parts of our code.
Hot Fix: This is the one that we are afraid to use, but we ended up using it because of the rush. We use the fix to upload some corrections. Usually, some bugs that we need to fix and get up to speed quickly in production.
Chore: We use chore when we make a change that doesn’t influence our system or any of our tests. To make it more transparent, we use chore for changes like adding something inside .gitignore, this doesn’t affect our system. Or change in eslint that would be just a config.
Style: Style is used for formatting or code style changes that do not influence the system logic.
Build: This one we use when we make any changes to our project’s build.
Test: As the name implies, the test would be when we make some changes in some project tests.
Perf: This one is little known, and people end up using Fix instead because we use perf when we make some change in the performance of our project, such as: improving the performance of a function or query.
Docs: This one ends up in Chore’s change package because it doesn’t change anything or Style, but we can use Docs when we make any changes to a documentation file such as swagger, readme, etc.
Pretty simple huh? And believe me, using these good practices helps a lot in our day-to-day 🙂
Well, that’s it guys. I hope you liked it and I see you in the next article. 🙂
*The content of this article is the author’s responsibility and does not necessarily reflect the opinion of iMasters.
Leave a comment