Keep a Changelog is a wide-used convention that brings some guidelines about the maintenance of a CHANGELOG.md file in repositories managed over a VCS.
I'm in doubt about how should it work when it comes of multiple commits of a unique release.
Since its text describes that "The same types of changes should be grouped" and its own repo CHANGELOG.md file brings the following:
...
## [1.0.0] - 2017-06-20
### Added
- New visual identity by [@tylerfortune8](https://github.com/tylerfortune8).
- Version navigation.
- Links to latest released version in previous versions.
- "Why keep a changelog?" section.
- "Who needs a changelog?" section.
...
However the same guideline follow Semmantic Versioning 2.0, that defines:
...
6. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.
7. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.
...
So I understand that each commit that introduces a bug-fix or a new feature should increase the PATCH or MINOR version respectively.
Is this right?
So I understand that each commit that introduces a bug-fix or a new feature should increase the PATCH or MINOR version respectively.
That is NOT true. There can be many commits leading up to a version bump. You bump the version when you publish your changes, not when you commit them. Note that for some workflows, "official" builds (run on the CI/CD systems) implies publication.