Skip to main content

Commit Messages

Write a good commit message​

Commit messages are one of the most common ways developers communicate with each other, so it’s important to clearly communicates any changes.

Typically, the audience of a commit message is:

  • People reading the commit timeline.
  • People debugging code

The Anatomy of a Commit Message​

  • Basic: git commit -m <message>

  • Detailed: git commit -m <title> -m <description>

5 Steps to Write Better Commit Messages​

Let's summarize the suggested guidelines:​

  1. Capitalization and Punctuation: Capitalize the first word and do not end in punctuation. If using Conventional Commits, remember to use all lowercase.
  2. Mood: Use imperative mood in the subject line.
    Example – Add fix for dark mode toggle state. Imperative mood gives the tone of an order or request.
  3. Type of Commit: Specify the type of commit. It is recommended and can be even more beneficial to have a consistent set of words to describe your changes.
    Example: Bugfix, Update, Refactor, Bump, and so on. See the section on Conventional Commits below for additional information.
  4. Length: The first line should ideally be no longer than 50 characters, and the body should be restricted to 72 characters.
  5. Content: Be direct, try to eliminate filler words and phrases in these sentences (examples: though, maybe, I think, kind of). Think like a journalist.

Why use a commit message convention?​

A well-organized commit message history leads to more readable messages that are easy to follow when looking through the project history.

The commit type can include the following:​

  • feat – a new feature is introduced with the changes
  • fix – a bug fix has occurred
  • chore – changes that do not relate to a fix or feature and don't modify src or test files (for example updating dependencies)
  • refactor – refactored code that neither fixes a bug nor adds a feature
  • docs – updates to documentation such as the README or other markdown files
  • style – changes that do not affect the meaning of the code, likely related to code formatting such as white-space, missing semi-colons, and so on.
  • test – including new or correcting previous tests
  • perf – performance improvements
  • ci – continuous integration related
  • build – changes that affect the build system or external dependencies
  • revert – reverts a previous commit