docs(Conventional Commits): Feat, Fix, Refactor… which is which?
Tags: webdev, programming, tutorial, git
Published: 2023-09-22 00:10:25

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`).