-
Notifications
You must be signed in to change notification settings - Fork 9
Commit Message Guidelines
In a (new) effort to make commits easier to review and to follow a consistent format, we encourage our commits to follow this guideline.
The structure of a commit message should be as follows.
<type>(<scope>): <subject>
<body>
<footer>
Required: If your commit does not fit into one of the following types, you should consider making several smaller commits. The following types are recommended.
- fix : bug fix
- feat: new feature
- test: changes related to testing - new tests or changes to existing tests
- refactor: non-functional code changes - moving packages, renaming classes
- style: non-code changes - code formatting, header updates
- build: related to gradle, releasing or the ci
Optional: The area in the plugin that this change affected. Try to keep short and omit when unnecessary. The following scopes are recommended.
- The modules: inspection, scan, policy ...
- The configuration: properties, verification ...
Required: A brief description of the commit, the shorter the better. Full sentences with capitalization and periods.
Optional: A place to discuss the reason for this commit and the changes included in it. Full sentences with capitalization and periods.
Optional: Use the footer to reference issues, whether from github or jira. Capitalized but with no period. In general, the following formats are recommended.
Fixes <issue>Related to <issue>
fix(notifications): Notification endpoint has user permission problems.
Fixes IARTH-226
style: Updating headers.
fix(diagnostics): Diagnostic mode using the wrong logger name.
When we renamed our packages from black duck to synopsys the diagnostic logger name was not updated. It used the name to get the correct logger.
build: Using new libraries.
refactor(propertyService): Renamed getters to resolve*.