Hey great thing you are interested! Full story short, think about your public, and ask yourself: - Am I introducing a new feature to my users? -> feat - Am I f

Hey great thing you are interested! 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. Examples and more info: - https://github.com/angular/angular/blob/22b96b96902e1a42ee8c5e807720424abad3082a/CHANGELOG.md https://github.com/angular/angular/blob/22b96b96902e1a42ee8c... - https://github.com/conventional-changelog/standard-version https://github.com/conventional-changelog/standard-version - https://www.conventionalcommits.org/en/v1.0.0-beta.4/#about https://www.conventionalcommits.org/en/v1.0.0-beta.4/#about Hope I was helpful, Regards!