I’ve been using git for almost a decade now and I don’t understand how conventional commits work. The docs make no sense to me: https://www.conventionalcommits.org/en/v1.0.0-beta.3/#specif... , full specification states there are only two types of them - fix and feat. Then they point you in the direction of https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING... and at this point I wasn’t even sure if there’s a golden standard or can I go with “anything: foo”? I really tried to use this methodology but as a front end had to push a lot of CSS changes and I didn’t know where they belong to, is it refactor if I change border color? Or maybe “style”? But according to the guideline style is for code styles like white space or missing semicolon but isn’t that refactor? I’m dumb maybe but I feel like it’s incredibly complex for such a small thing. If I move one Sass rule few lines up and the whole layout changes due to specificity changes - is it a refactor, new feature or style and what if it fixes a bug? :( Could you explain it to me? I’d love to stick to the naming once I get it, the profit seems to be quite big especially if in 10 years I want to let’s say parse and analyze my code. Thanks!
TL;DR what commit type to use for css and what if one commit seems to fit for multiple types?
Full story short, think about your public, and ask yourself:
- Am I introducing a new feature to my users? -> feat
- Am I fixing something, with no new functionality? -> fix
- Is my change breaking the API for my consumers? -> add BREAKING CHANGE to the body of your message, no matter what prefix you are using.
This 3 map closely to semantic versioning and are used in conventional-changelog.
MAJOR -> BREAKING CHANGE
MINOR -> feat
PATCH -> fix
Now, sometimes, this 2 prefixes might not be enough to describe what you have done. Maybe you introduced a new ci, that's no code, doesn't need to use one of the aforementioned prefix, so you use one of the optionaly proposed Angular prefixes (I think conventional commits is based on angular originally).
Sometimes fix might not be good enough to describe what you changed, in that case you can use `perf:` or `improvement`, but remember that this changes should not introduce anything to your consumers, let's say you converted a sass code that was too repetitive into a for loop.
TL;DR: use feat and fix, they map to semver and you can generate the changelog automatically.
TL;DR what commit type to use for css and what if one commit seems to fit for multiple types?