Skip to content

Commit messages (semantic versioning)

Alan B. Christie edited this page Feb 19, 2026 · 1 revision

You might want to consider adopting a conventional commit style for your commit messages. A significant advantage of a consistent style like this is that you could also automate the creation of your tags, which is especially beneficial is you're using semantic-style of tags.

Essentially your commit messages would consist of a type prefix prior to the (brief) description. You then decide whether your commit FIXES something (i.e. a new PATCH release), provides a new FEATURE (adding new functionality), or introduces a BREAKING CHANGE. The advantages of this approach is that you can further utilise other tools that will automatically tag your repository when you need to and update any CHANGELOG you choose to maintain.

Conventional commits also accommodate other types of software change, including changes that: -

  • Are stylistic where nothing is fixed, and no features are added (style:, refactor:, perf:)
  • Relate to documentation (docs:)
  • Adjust test code (test:)
  • Affect the build (build:)

Commitizen is one such tool, that can enforce your commit style and help you automate the tag generation (based on the commit message content) as well as update your CHANGELOG.


Clone this wiki locally