Types

[robertveloso]

Add to the readme the reason for the types chosen, as we (students) try to follow the patterns used by you.

[pellizzetti]

Hi @robertveloso! 👋

There's not much to say, Conventional Commits [as of v1.0.0-beta.4] states the following:

The commit contains the following structural elements, to communicate intent to the consumers of your library:

1. fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in semantic versioning).
2. feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in semantic versioning).
3. BREAKING CHANGE: a commit that has the text BREAKING CHANGE: at the beginning of its optional body or footer section introduces a breaking API change (correlating with MAJOR in semantic versioning). A BREAKING CHANGE can be part of commits of any type.
4. Others: commit types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommends chore:, docs:, style:, refactor:, perf:, test:, and others.

With these base guidelines I aimed to make a reusable commitlint config that could be shared among our projects (public and private). With that I ended up with the following:

feat: Introduces a new feature;
fix: Patches a bug;
docs: Introduce or change anything related to documentation. Should also be used for meta docs;
ci: Related to the Continuous Integration of the project;
test: Introduces/Refactor tests;
chore: Anything not covered by the previous types. This is usually used in minor adjustments, refactor, style/perf changes, et al. [This is, by far, the most commonly used.]

This covered all our needs and still does but it will probably be changed in the near future, this kind of config should be something that changes and evolve based in your needs, so if you feel that it'll be of use go ahead and feel free to use it but I would recommend that you create your own config! ❤️