Skip to content

Commit Message

Jump to bottom
Crux Cook edited this page Jan 8, 2024 · 4 revisions

Contents

Commit Message Format

<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The header is mandatory with length <= 50 characters.

The body is optional with length <= 72 characters.

The footer is optional.

Exp:

feat(router): add random number generator

Implement random library to generate number.

Issue #5

Set up rulers to calculate characters

$ git config core.editor "code --wait"

# VSCode (settings.json)
"[git-commit]": {
  "editor.rulers": [50, 72]
}

Commit Message Header

<type>(<scope>): <short summary>
  │       │             │
  │       │             └─⫸ Summary in present tense. Not capitalized. No period at the end.
  │       │
  │       └─⫸ Commit Scope: A noun represents the section of the code base & written in lowercase.
  |                          Ex: animations|compiler|compiler-cli|elements|forms|http|
  |                          language-service|platform-browser-dynamic|router|
  |                          upgrade|zone.js|packaging|changelog|docs-infra|migrations|devtools
  │
  └─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test

The <type> and <summary> fields are mandatory, the (<scope>) field is optional.

Commit Message Type

  • feat: Adds new features
  • fix: Fixes bugs
  • docs: Documentation changes
  • perf: Changes related to performance
  • test: Adds needed tests or corrects existing tests
  • build: Changes for build or setup (npm, dependencies, CI/CD, build tool, project version, etc)
    • chore: Grunt tasks, no production or testing code changes (.gitignore, .gitattributes, etc)
  • ci: CI/CD configuration changes (Jenkins, Travis, SauceLabs, etc)
    • container: Container configuration changes (Docker, Kubernetes, etc)
  • refactor: Rewrites/Restructures code but not changing any behaviours (neither fixes a bug nor adds a feature)
    • revert: Brings back a previous commit (not recommended, create a new merge instead)
    • style: Changes related to coding style (indentation, brackets, new lines, etc)

Worth mentioning (need to verify usage)

  • release: identifies a commit for an official release
  • security: changes related to project privacy/security (credentials, etc)
  • ops: operations changes (deployment, backup, recovery, infrastructure, etc)

Note:

  • Uses imperative, present tense ("add" instead of "adds" or "added").
  • No dot(.) at end.
  • No capitalize first letter.
  • Use "not" instead of "dont" or "doesnt".
  • Use "resolve", "address", "correct" or equivalent verbs when writing a fix title message.

Commit Message Body

  • Uses imperative, present tense ("add" instead of "adds" or "added").
  • Should explain WHY making the change (NOT how). Can include a comparison of the previous behavior with the new behavior in order to illustrate the impact of the change.
  • Limits line at 72 chars.
  • Adds new line between paragraphs.
  • Do NOT add new line between elements in unordered list.
  • Avoid Markdown syntax as MD is not fully supported on all Git platforms.

Commit Message Footer

  • Contains BREAKING CHANGE, DEPRECATED, external links, issue reference and other meta-information.
  • BREAKING CHANGE, DEPRECATED must be indicated at the very beginning of the footer, adds ! right after commit type to draw attention. Exp
<type>(<scope>)!: <short summary>
<BLANK LINE>
<body content>
<BLANK LINE>
BREAKING CHANGE: <breaking change summary>
<BLANK LINE>
<breaking change description + migration instructions>
<BLANK LINE>
<BLANK LINE>
Issue #<issue number>

Note:

  • Uses `` for code reference.
  • Uses [] for link reference, e.g.
<body>
[Something] is mentioned here.

<footer>
Links:
[Something]: hyperlink

Reference

See also

Clone this wiki locally