Conventional commit messages

[j4-m]

As we are using semantic versioning it is critical to understand the nature of the changes when creating releases. For example, if the release branch has some commits on it which have not been released then when the next release it is created we need to know if it just bug fixes or if it includes new features or even breaking changes so we choose the appropriate SemVer.

This is exactly what the Conventional commits specification exists for. I suggest we adopt our own flavour of the specification and document it in the wiki.

[stephen-cox]

If I understand the underlying reason for this it is to identify the different types of changes that are being released. Having some guidelines for this sounds good.

I generally include the GitHub issue and PR numbers in the commit message so it's possible to identify what is being fixed. For large feature requests with lots of commits I squash all the commits, ensuring the main line describes the feature and includes issue and PR numbers with the commit message body including lines for the major functionality added.

[ekes]

For large feature requests with lots of commits I squash all the commits, ensuring the main line describes the feature and includes issue and PR numbers with the commit message body including lines for the major functionality added.

For anything that really deserves it's own branch to work on I think this is the thing. I tend to come at this from the perspective of a git blame user, someone trying to understand why what was done. Linking to issues and discussion here is super valuable. For some things doing an interactive rebase to make it two or three commits that make logical sense and have a good description, rather than just one squash.

[millnut]

Quite an old issue but it would be good to bring conventional commits up for discussion again. Personally I find it very handy to be able to scan git logs for breaking changes (i.e. large module dependency jumps, class/function/namespace renames, etc.), refactoring, test-specific commits etc. at a glance rather than finding an issue ticket and then digging into that or actually loading the commit to work out the level of changes.

A big benefit of adopting this would be consistent git commits from everyone involved (we could implement a pre-commit to ensure the standard is followed) and we could start using some automation for changelogs using the commit messages.