This document/workshop/tutorial was created to standardize and structure the commits made by our team. Doing so helps us maintain a cleaner and more organized repository, which gives us the advantage of “traveling in time” to quickly identify potential errors in older implementations, maintaining a better history of changes, and keeping better track of what’s being done on the development side of the project to justify it to the client.

Basic concepts

Conventional commits is a specification that provides a lightweight framework for maintaining, organizing, and standardizing project git commits. It provides a set of easy rules to maintain a clean and explicit history of commits and changes. By following the Conventional Commits specification, developers can create a more organized and transparent repository, which can improve collaboration, code quality, and project management.

The provided structure by Conventional commits has the next shape:

<type>[optional scope]: <description>
[optional body]
[optional footer(s)]	

When writing a commit description, the convention is generally to follow the colon “:” with a space, use lowercase, and then use an infinitive verb such as ‘add’, ‘remove’, ‘change’, or ‘call’. It is also best to be concise and clear about the objective of the commit, avoiding the use of more than one line in the commit message or PR.

Additional details can be added in the body of the commit, but overloading the information is unnecessary. Here, we can include any information that will help other developers review and contribute to our PR, as well as provide greater context. For example, in our specific case, it is helpful to include the ticket URL to better track the project. We can also include links to other comments in Github, screenshots, videos of behaviors, notices, or explanations of certain implementations. Here we can see an example of how we can use the body:

feat: add new login feature

This commit adds a new login feature to the application, which allows users to log in using their email address or username.

The new login feature is accessible from the login page, and users can choose to log in using either their email address or their username.

Fixes #123

And the footer:

chore: update broken link in README

The link to the documentation in the README was broken. This commit updates the link to the correct URL.

Fixes #456

Co-authored-by: Jane Doe <>

Types of commits, the most tricky important

We have a wide set of types to describe our changes:

Remember, as with all good coding practices:

Now you can just get along with your day coding, testing, and drinking a lot of energy drinks, coffees, or mates.

Thanks for reading!