If you use or are in a team that uses Conventional Commits, maybe you’re confused about which one to use in your commit. So, let’s try to make it clear which one it is!
For this to work, let’s assume you write perfect code with 1000% test coverage (think unit, integration, e2e, mutation, performance…) unless stated otherwise.
Feat
A commit of feat means you’ve added or removed src code, but since you started with 1000% coverage, something is either not covered by tests or tests broke.
Fix
A commit of fix means that if you were to add a new test reproducing a bug, it would not pass. In this case, the commit will make that test pass.
Refactor
A commit of refactor means that you changed src code but unlike feat no tests broke and no lines lost coverage.
Perf
A commit of perf, like refactor means changed src code, but in this case performance metrics go up.
Style
A commit of style, like refactor means changed src code, but instead of actual code changes, only formatting and whitespace are changed. In other words, anything a code formatter or linter changes.
Docs
A commit of docs usually means a change in markdown files.
I also add as docs changes, comments in src code when only comments are changed.
Test
A commit of test means changes in test files. If you weren’t at 100% code coverage, now you would be. If you had failing tests, they would be passing.
CI
A commit of ci means changes related to Continuous Integration (usually yml and other configuration files).
Build
A commit of build means changes related to the build of the project and dependencies. (Basically, anything that can change the build step of the application.)
Chore
A commit of chore is most likely something that doesn’t fit the other possible types. It shouldn’t change any src, test, build, or docs related files.
Revert
A commit of revert simply reverts changes made in another commit.
(Personally, I think it’s better to revert a commit using git, which is also why atomics commits make this easier since other unrelated files aren’t changed.)
Remarks
There are a lot of types and a lot of shadowing between some.
Both perf and style are (or can be) just refactors, so you can use those if possible and refactor for other cases. But, perf can also be a feat depending on the changes. perf in this case is better, but as you go you’ll find others.
build and ci might overlap, so you have to choose one (usually pick the one you’re solving), but if all fails, sometimes a chore is a “catch-all” for when you don’t know what to use.
Not only that, do you commit changes for tests when adding new feat or fix? What about refactor of test files?
This is to say there is some flexibility, but as with everything else… it ****depends****.
While I usually try to go as atomic as possible (to the point of splitting commits of lines in the same file when it makes sense to) I will still commit changes in tests (or new ones) together with adding some new functionality or when fixing something (in those cases as a feat or fix).
Top comments (0)