-
Notifications
You must be signed in to change notification settings - Fork 79
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 detect that this change affected. Try to keep short and omit when unnecessary. The following scopes are recommended.
- The package manager: npm, gradle ...
- The tool: sigscan, polaris, blackduck ...
- The lifecycle: boot, run, spring ...
- The package: property, help, options, diagnostics ...
Required: A brief description of the commit, the shorter the better. Full sentences with capitalization and dots.
Optional: A place to discuss the reason for this commit and the changes included in it. Full sentences with capitalization and dots.
Optional: Use the footer to reference issues, whether from github or jira. Capitalized but with no dot. In general, the following formats are recommended.
Fixes <issue>Relates to <issue>
fix(file): Won't follow symlinks during traversal.
Fixes IDETECT-1166
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: Polaris uses getters for connection status.
Related to IDETECT-1238