Semantic Commit Messages

semantic-commit-messages.md

Semantic Commit Naming and Messages

Format: <type>(<scope>): <subject> <description>

<scope> is optional

<description> is also optional

git commit -m "<type>(<scope>): <subject>" -m "<description...>"

Example

docs(articles): add 2 unhappy test scenarios
^--^  ^------------^
|     |
|     +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test

Types

• chore: (updating grunt tasks etc; no production code change)

• docs: (changes to the documentation)

• style: (formatting, missing semi colons, etc; no production code change)

• test: (adding missing tests, refactoring tests; no production code change)

• ci: (ci/cd changes)

• 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)

• hotfix: (bug hotfix for the user, not a fix to a build script)

• refactor: (refactoring production code, eg. renaming a variable)

• debt: (refactoring production code due to the tech debt)

Breaking Changes Indicator

Breaking changes should be indicated by an ! before the - in the subject line, e.g.

feat(api)!: remove status endpoint - it's an optional part of the format though

Semantic Branch naming convention

Instance <-> branch

Instance	Branch	Description
Production	main|production	Accepts merges from Staging and Hotfixes
Staging | Develop (Developing)	staging	Accepts merges from Features/Issues, Bugfixes and Hotfixes
Features/Issues	feature/*	Always branch off HEAD of Staging|Develop
Bugfixes	fix/*	Always branch off Staging|Develop
Hotfix	hotfix/*	Always branch off Master
Tech Debt	debt/*	Always branch off Staging|Develop
Test	test/*	Always branch off Staging | Develop

Standard approach - issue-scope-branch

Format: <issue-type>/<issue-number>_<branch-name>

where issue-type is fix/hotfix/task/feature etc where issue-number is JIRA/IssueNumber

e.g.:

task/JIRA-578_E2E_add_getArticles_tests

feature/JIRA-578_E2E_pdf_conversion_tests

task/JIRA-10499_API_add_info_to_log

Different approach - branch-author

Format: <branch-author>/<branch-type>/<branch-name>

where branch-author == <autor name or initial> is used for maintaining a point-of-contact context and makes it easy to group/search commits:

git branch --list '{author}/feature/*'

References:

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