Semantic Commit Messages

See how a minor change to your commit message style can make you a better programmer.

This follows the guidelines provided in Conventional Commits

Format of title: <type>(<scope>): <subject>

<scope> is optional

This should be short enough that it can be read quickly within Github or any git commit history tool.

Format of body: <Describe intent behind commit, rationale and issues faced>

This enables any engineer to review commits to understand why things have been done in a particular way. This is optional if the title doesn't provide enough context

Format of footer: <Jira ticket ID('s)>

This enables Jira integrations with Github to automatically reference commits directly to commits, and enables audit traceability for future engineers to understand the intent behind the work with acceptance criteria behind the change.

Whilst not strictly necessary, it enables changes made to the repo to be directly traceable to work items viewable to other people.

Example of full commit message

feat: Adding original `attendeeCategory` to `fasDetails`

This is so we can audit the original `attendeeCategory` when the submission has been rejected in FAS

DG-1756

More Examples:

• feat: (new feature for the user, not a new feature for build script)
• fix: (bug fix for the user, not a fix to a build script)
• docs: (changes to the documentation)
• style: (formatting, missing semi colons, etc; no production code change)
• refactor: (refactoring production code, eg. renaming a variable)
• test: (adding missing tests, refactoring tests; no production code change)
• chore: (updating grunt tasks etc; no production code change)

References:

• https://www.conventionalcommits.org/
• https://seesparkbox.com/foundry/semantic_commit_messages
• http://karma-runner.github.io/1.0/dev/git-commit-msg.html
• https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716