Skip to content

Instantly share code, notes, and snippets.

@wgnf

wgnf/Conventional Commits.md

Last active November 16, 2021 08:14
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save wgnf/bc8b32e483a93db51d0a12f356de1fe7 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save wgnf/bc8b32e483a93db51d0a12f356de1fe7 to your computer and use it in GitHub Desktop.
Download ZIP
Conventional Commits
Raw
Conventional Commits.md

Conventional Commits

(adopted from Angular and based on Conventional Commits)

Message Format

Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The header is mandatory and the scope of the header is optional.

Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.

The footer should contain a closing reference to an issue if any (i.e. links to MR/PRs or Issues).

BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.

Types

Can be one of the following:

  • build: Changes that affect the build system or external dependencies (example scopes: cake, nuke, nuget, ...)
  • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
  • docs: Documentation only changes
  • feat: A new feature
  • fix: A bug fix
  • perf: A code change that improves performance
  • refactor: A code change that neither fixes a bug nor adds a feature
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • test: Adding missing tests or correcting existing tests
  • log: Add additional log messages for more clarity
  • chore: updating stuff, no production code change

Scopes

Can be any scope that is defined by the project (i.e. compiler, frontend, backend, ...), that defines what scope the commit was for.

Subject

The subject contains a succinct description of the change:

  • use the imperative, present tense: "change" not "changed" nor "changes"
  • don't capitalize the first letter
  • no dot (.) at the end

Body

Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.

Footer

The footer should contain any information about Breaking Changes and is also the place to reference Issues that this commit Closes.

Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment