Skip to content

Commit Message Guidelines

Jordan Piscitelli edited this page Mar 3, 2020 · 7 revisions

In a (new) effort to make commits easier to review and to follow a consistent format, we encourage our commits to follow this guideline.

Overview

The structure of a commit message should be as follows.

<type>(<scope>): <subject> (<footer>)

<body>

Type

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 compiling or generating artifacts
  • chore: tasks or things related to non-source files (editing the readme or privacy policy)
  • ci: related to configuration files and scripts for things like travis and jenkins
  • docs: changes to documentation

Scope

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 ...

Subject

Required: A brief description of the commit, the shorter the better. Full sentences with capitalization and periods.

Body

Optional: A place to discuss the reason for this commit and the changes included in it. Full sentences with capitalization and periods.

Footer

Optional: Use the footer to reference issues, whether from github or jira. Capitalized but with no period. In general, the following formats are recommended. Try to reference only a single issue and match one of the following formats.

  • (<issue>): Shorthand for Fixes.
  • (Fixes <issue>): Use when this commit fixes the given issue.
  • (Related to <issue>): Use when this commit is a consequence of or related to the given issue.

Examples

fix(filefinder): Won't follow symlinks during traversal. (Fixes IDETECT-1166)
fix(bazel): Properly handling an NPE. (IDETECT-2122)
style(bazel): Removing extra new lines. (Related to IDETECT-2122)
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): Polaris uses getters for connection status. (Related to IDETECT-1238)
refactor(npm): Renamed npm project dependencies to declared dependencies to better indicate intent. (Related to IDETECT-1209)
Clone this wiki locally