Git commit messages are used for changelog generation. Because of this, it is important that the Git commit message format is standardized and no deviations cause incorrect changelogs to be generated.
As a standard, we make use of Conventional Commits.
Therefore, any Git commit message should adhere to the following format:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Here, <> denotes a required element, whereas [] denotes an optional field.
Where <type> is the type of contribution, which can be one of:
featA feature.fixA fix.testA test-related change.styleA style correction.perfA performance improvement.ciA change related to CI.buildA change related to building this project (dependencies, fixes, etc.).docsDocumentation change.refactorNone of the above.
Where [optional scope] is the scope of the change, such as App, Lib, as these can vary over time, coordination and adherence to previously used scopes is important.
Where <description> is the short description of the change. It is important that the description starts with a capital and ends with a full stop. The short description will directly show up in the changelog, therefore the description must make sense within that context.
Where [optional body] is a long description of the change.
Where [optional footer(s)] is a place for optional information, such as linking to issues, merge requests, etc. as is described here.
An example of a commit message:
fix(Lib): Resolved a null pointer causing crash during image load.
Fixed a null pointer in the PNG loader that caused PNG image loading to crash whenever a 16-bit image would be loaded.
Resolves #14.
For reverting, the revert scope should be used, followed by the description of the commit that is reverted.
For example:
revert: Resolved a null pointer causing crash during image load.
Refs: e4231f6e
To contribute, fork this repository and create a pull request to the develop branch.
In order to create a release, update the version in config.py in your fork
and create a pull request to develop. You can use the script
scripts/bump_version.sh to set the version and automatically create a
commit for it.
Then, create a pull request from develop to master.