fransafu

Hi There!

The commit conventions are very useful when trying to explain to a group of developers (maybe colleagues) about your changes. In the Code Review the implicit explanation of your changes is a powerful tool for their understanding and probably an advantage because you can complement your changes with your explanation, so that means you need less time to explain and improve the understanding of the case for your colleagues.

A few examples of commits using conventions are as follows

As a developer, I add all the files for the home page

feat(web): Add home page

As a developer, I fix a problem in middleware validation

fix(middleware): Add validation when user is null

So, how can I know the "format" to do commits with conventions? First of all, the following links are a "guide" to check but don't forget "conventions are conventions, not a rule"

Links:

Now, I leave you a table with the conventions that I usually use

format	Name	Description	Examples
feat	Features	Introduces a new feature to the codebase	A new view, new service, new function or process
fix	Bug Fixes	patches a bug in your codebase	Validation if not null in a condition with that problem
build	Builds	Changes that affect the build system or external dependencies	Update a dependency or changes in the build project scripts
docs	Documentation	Documentation only changes	Add the documentation for run the project or test
chore	Chores	Other changes that don't modify src or test files	Changes IDE or editor code configs
style	Styles	Changes that do not affect the meaning of the code	White-space, formatting, missing semi-colons, etc
refactor	Code Refactoring	A code change that neither fixes a bug nor adds a feature	Rename filename, change variable names, etc
test	Tests	Adding missing tests or correcting existing tests	Add or modify unit test, e2e test, integration test, etc.
ci	Continuous Integrations	Changes in CI configuration files and scripts	Add or modify script for deploy, build, security, lint, etc.

That's all, thanks for reading!