Skip to content

Commit Message Guidelines

Jump to bottom
Jordan Piscitelli edited this page Apr 2, 2019 · 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 gradle, releasing or the ci

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. 'Fixes' and no description along with an mean the same thing.

  • (<issue>)
  • (Fixes <issue>)
  • (Related to <issue>)

Examples

fix(filefinder): Won't follow symlinks during traversal. (Fixes IDETECT-1166)

fix(bazel): Properly handling an NPE. (IDETECT-1199)

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