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?
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.
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.
Semantic commits have a default skeleton consisting of optional parts that may or may not be added.
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.
Where should be described what was done in the commit in a simplified way.
Optional part that can contain a more detailed description of what was done in the commit.
Optional part that contains information related to closing an issue or belonging/association with a task.
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!