Conventional Commits: a better way to write commits git messages

Introduction

In my studies of Git, I doubted if existed a standard for if to orientation in the elaboration of commits. I was searching to keep a history of commits that were readable and to transmit a facility for me and other people that can access my codes. So, I had contact with Conventional Commits and decided to write about what I learned studying this specification.

Learning more about Conventional Commits

The simple definition for Conventional Commits is to be a convention that defines rules to be used in the commits messages. The main goal is to create a history of commits readable and to do that the development of software will be easier to understand about corrections and updates in the project.

In the documentation, we can see too a strong connection with the Semantic Versioning and too with documentation of Angular, both them with base for to get a clear and objective methodology. We can win some benefits, how to automatize the creation of logs, better communication of the nature of changes accomplish in the project, and a rise in productivity.

Structure of Conventional Commits

<type>[scope optional]: <description>
[ body optional ]
[ footer optional ]

The structure of commit that uses the Conventional Commits is very simple, owning attributes options, and requires that do easier your use in the projects.

Header

Starting the structure of that standard of commit, we have the header that should mandatorily it had a type and a description, in the case of the scope, it becomes optional.

In the type attribute, we have how to follow the documentation of Angular Commit Message Guidelines, where it has some types pre-defined. For description, we necessarily need to express in a few lines about changes that were executed in that determinate commit.

Types of commits

build: used for alterations that affect the system of compilation or external dependencies

ci: used for alterations in our files and scripts of configuration od CI;

docs: used only when to happen changes in documentation;

feat: used for when to add a new resource;

fix: used for a bug fix;

perf: used for alteration in code that improves performance;

refactor: used for when happen an alteration in the code, but not to correct no bug and not have added a resource;

style: used for alterations that do not affect the meaning of code;

test: used for adding tests or correcting existing tests

For example:

fix: remove createUser wrong attribute

Scope

The scope is an attribute optional and is information that is inside parentheses after the type of commit. Your use happens more when we need to write a detailing or indeterminate situation.

Subject

For to finish the structure of the header, the description is required and should start with the letter lowercase. Also is a need to use the imperative and not use the point(.) in the final subject.

Body

How apart is optional, the body can be used to describe more details about changes in the code. Another point important about him is the fact that he needs will be written using imperative.

The footer not is required, your use is more associated to the closure of troubles that this commit in question closes.

The word BREAKING CHANGE: with a space or two new lines, is the format indicated for to write this structure of the footer.

Conclusion

When using the Conventional Commits we can be sure that your implementation brings many improvements to the development team, how also, to a developer beginner. This convention allows the process will be easier and keep a good history of commits that help other developers or people when they will see the documentation of our projects.

Thanks for reading and may the force be with you!

References

https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines https://www.conventionalcommits.org/en/v1.0.0/ https://semver.org/