Skip to content

Instantly share code, notes, and snippets.

@jerodg

jerodg/git_conventional_commit_cheat_sheet.adoc

Last active July 30, 2025 06:44
Show Gist options
  • Save jerodg/074496e1e0014faeeaed34fb1ef64cd9 to your computer and use it in GitHub Desktop.
Save jerodg/074496e1e0014faeeaed34fb1ef64cd9 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. jerodg revised this gist Aug 22, 2024. 1 changed file with 35 additions and 7 deletions.
    42 changes: 35 additions & 7 deletions git_conventional_commit_cheat_sheet.adoc
    View file
    Original file line number Diff line number Diff line change
    @@ -24,6 +24,7 @@
    = {description}

    == Types

    [options="header"]
    |===
    | Type | Description | Example
    @@ -44,13 +45,33 @@

    [source,highlight,plaintext]
    ----
    <type>[optional scope]: <description>
    <type>([optional scope]): <description>
    [optional body]
    [optional admonition] [optional body]
    [optional footer]
    ----

    NOTE: 1. Use + for addition +
    2. Use - for removal +
    3. Use ~ for change +
    4. Use ! to draw attention (e.g. breaking change)

    == Example

    [source,highlight,plaintext]
    ----
    fix(etl)!: prevent racing of requests
    + Introduce a request id and a reference to latest request.
    - Remove timeouts which were used to mitigate the racing issue but are obsolete now.
    ~ Modify the request handling logic to prevent racing.
    Refs: #123
    BREAKING CHANGE: Use JavaScript features not available in Node 6.
    ----

    NOTE: Refs are references to issues or pull requests.

    == Specification

    @@ -59,14 +80,21 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
    . Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by a colon and a space.
    . The type feat MUST be used when a commit adds a new feature to your application or library.
    . The type fix MUST be used when a commit represents a bug fix for your application.
    . An optional scope MAY be provided after a type. A scope is a phrase describing a section of the codebase enclosed in parenthesis, e.g., fix(parser):
    . A description MUST immediately follow the type/scope prefix. The description is a short description of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.
    . A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
    . A footer MAY be provided one blank line after the body. The footer SHOULD contain additional issue references about the code changes (such as the issues it fixes, e.g., Fixes #13).
    . Breaking changes MUST be indicated in the footer AND by appending a ! after the type/scope. A BREAKING CHANGE introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
    . An optional scope MAY be provided after a type.
    A scope is a phrase describing a section of the codebase enclosed in parenthesis, e.g., fix(parser):
    . A description MUST immediately follow the type/scope prefix.
    The description is a short description of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.
    . A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes.
    The body MUST begin one blank line after the description.
    . A footer MAY be provided one blank line after the body.
    The footer SHOULD contain additional issue references about the code changes (such as the issues it fixes, e.g., Fixes #13).
    . Breaking changes MUST be indicated in the footer AND by appending a ! after the type/scope.
    A BREAKING CHANGE introduces a breaking API change (correlating with MAJOR in Semantic Versioning).
    A BREAKING CHANGE can be part of commits of any type.
    . A description MUST be provided after the BREAKING CHANGE:, describing what has changed about the API, e.g., BREAKING CHANGE: environment variables now take precedence over config files.
    . The footer MUST only contain BREAKING CHANGE, external links, issue references, and other meta-information.
    . Types other than feat and fix MAY be used in your commit messages.

    == References

    https://www.conventionalcommits.org/[Conventional Commits]
  2. jerodg revised this gist Aug 22, 2024. 1 changed file with 2 additions and 1 deletion.
    3 changes: 2 additions & 1 deletion git_conventional_commit_cheat_sheet.adoc
    View file
    Original file line number Diff line number Diff line change
    @@ -24,8 +24,9 @@
    = {description}

    == Types

    [options="header"]
    |===
    | Type | Description | Example
    | ```feat``` | Features | A new feature
    | ```fix``` | Bug Fixes | A bug fix
    | ```docs``` | Documentation | Documentation only changes
  3. jerodg revised this gist Aug 22, 2024. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion git_conventional_commit_cheat_sheet.adoc
    View file
    Original file line number Diff line number Diff line change
    @@ -19,7 +19,7 @@
    :stylesheet: styles.css
    :description: Conventional Commit Cheat Sheet
    :keywords: git, conventional, commit, cheat, sheet
    :url-repo:
    :url-repo: https://gist.github.com/jerodg/074496e1e0014faeeaed34fb1ef64cd9

    = {description}

  4. jerodg created this gist Aug 22, 2024.
    71 changes: 71 additions & 0 deletions git_conventional_commit_cheat_sheet.adoc
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,71 @@
    :author: JerodG
    :email: [email protected]
    :docdate: 22 Aug 2024
    :revdate: {docdatetime}
    :doctype: book
    :experimental:
    :sectanchors: true
    :sectlinks: true
    :sectnumlevels: 5
    :sectids:
    :sectnums: all
    :toc: left
    :toclevels: 5
    :icons: font
    :imagesdir: ../images
    :iconsdir: ../icons
    :stylesdir: ../styles
    :scriptsdir: ../js
    :stylesheet: styles.css
    :description: Conventional Commit Cheat Sheet
    :keywords: git, conventional, commit, cheat, sheet
    :url-repo:

    = {description}

    == Types

    |===
    | ```feat``` | Features | A new feature
    | ```fix``` | Bug Fixes | A bug fix
    | ```docs``` | Documentation | Documentation only changes
    | ```style``` | Styles | Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
    | ```refactor``` | Code Refactoring | A code change that neither fixes a bug nor adds a feature
    | ```perf``` | Performance Improvements | A code change that improves performance
    | ```test``` | Tests | Adding missing tests or correcting existing tests
    | ```build``` | Builds | Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
    | ```ci``` | Continuous Integrations | Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
    | ```chore``` | Chores | Other changes that don't modify src or test files
    | ```revert``` | Reverts | Reverts a previous commit
    |===

    == Commit Message Structure

    [source,highlight,plaintext]
    ----
    <type>[optional scope]: <description>
    [optional body]
    [optional footer]
    ----


    == Specification

    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in https://www.ietf.org/rfc/rfc2119.txt[RFC 2119].

    . Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by a colon and a space.
    . The type feat MUST be used when a commit adds a new feature to your application or library.
    . The type fix MUST be used when a commit represents a bug fix for your application.
    . An optional scope MAY be provided after a type. A scope is a phrase describing a section of the codebase enclosed in parenthesis, e.g., fix(parser):
    . A description MUST immediately follow the type/scope prefix. The description is a short description of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.
    . A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
    . A footer MAY be provided one blank line after the body. The footer SHOULD contain additional issue references about the code changes (such as the issues it fixes, e.g., Fixes #13).
    . Breaking changes MUST be indicated in the footer AND by appending a ! after the type/scope. A BREAKING CHANGE introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
    . A description MUST be provided after the BREAKING CHANGE:, describing what has changed about the API, e.g., BREAKING CHANGE: environment variables now take precedence over config files.
    . The footer MUST only contain BREAKING CHANGE, external links, issue references, and other meta-information.
    . Types other than feat and fix MAY be used in your commit messages.

    == References
    https://www.conventionalcommits.org/[Conventional Commits]