What are Semantic Commits and how do I use them?
If you've heard about semantic commits, you probably know that this is standardization. But before we start talking, let's analyze a real scenario that maybe you've even been through.
Let's imagine you're at work and you pick up a new issue on your team's task board. After some time analyzing and reading the demand, you remember that your teammate did something very similar that could help you in the development of your task. Perfect! You'll look at the code, but you have no idea what part of it this is, and you don't remember when it was implemented in the project. Okay, so let's look at the commits. When analyzing, finding them is easier, as you go, you will see commits like “add new feature”, “add tests”, “fixing bug”.
With this scenario in mind, we would have to analyze commit by commit to find what we want. This can take a long time for something that was actually meant to make it easier. This is a common situation among many others within the job market involving commits. This is where our topic for today, the semantic commit, comes in! Come on?
What is semantic commit?
Semantic commit or conventional commit is a way of standardizing commits within the project using simple rules. With this standardization, it is possible to reduce the time spent to understand something in the code: when, where and why it was done. This time is reduced because just by looking at the git history, we can already identify what we are looking for, without opening commit by commit and analyzing the code.
how did it come about
The exact origin of how the concept of semantic commits came about is not known, but the first major project known to use commit standardization rules was the Angular repository on Github. Today we were able to find a project that attempts to formalize a convention for standardizing commits, the Conventional commit.
How to use
Semantic commits have a default skeleton consisting of optional parts that may or may not be added.
- Feat: Used when making any addition to the code. Its focus is to be used when there is a new functionality implementation in the system.
- Fix: Used when there are errors in the code that are causing bugs.
- Refactor: Used in code refactoring but that does not change its functionality.
- Style: Used when making a change in the style and formatting of the code.
- Chore: Used in the update for changes to tools, settings and libraries. Updates that do not change production code.
- Doc: Used when some documentation is added or updated in the project.
- Test: Used when making any changes to the project tests.
Scope
The commit scope has to be the part of the code that was modified. It is an optional part that should be short and easy to understand.
Description
Where should be described what was done in the commit in a simplified way.
Body
Optional part that can contain a more detailed description of what was done in the commit.
Baseboard
Optional part that contains information related to closing an issue or belonging/association with a task.
adapt and use
As we can see in the skeleton of a semantic commit, many parts are optional. What we can do is see what best fits our day to day, project and team. A commit that will help you is not necessarily one that has all the skeleton parts. Sometimes using everything can even be a bad thing, given the size and time it takes. Therefore, the best thing to do is analyze and see the best way for you and your team. The essential thing is that it is clear and objective, so that anyone knows where and what was done in that commit. If you liked the content and want to learn in-depth and hands-on about semantic commits, check out our Complete Web Full Stack Training!
Dont miss out on the news!
Join the MAKE NOW academy to receive exclusive content every week!