Commit Message Format

Source: Dev.to

Commit Message Format

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

<type>(<scope>): <subject>

The header is mandatory; the scope is optional.

Example – fix: remove unused dependency lodash.camelcase

Any line of the commit message must be no longer than 100 characters. This keeps the message readable in GitHub and various Git tools.

Type

Must be one of the following:

• feat: A new feature.
• fix: A bug fix.
• docs: Documentation only changes.
• style: Changes that do not affect the meaning of the code (whitespace, formatting, missing semicolons, etc.).
• refactor: A code change that neither fixes a bug nor adds a feature.
• perf: A code change that improves performance.
• test: Adding missing tests.
• chore: Changes to the build process or auxiliary tools and libraries (e.g., documentation generation).
• ci: Changes to CI configuration files and scripts.
• build: Changes that affect the build system or external dependencies (e.g., gulp, broccoli, npm).
• revert: Reverts a previous commit.
• wip: Work in progress; the commit may be removed later.

Scope

The scope is optional and can specify the area of the codebase the change affects, e.g., nsis, mac, linux, etc.

Subject

The subject contains a succinct description of the change:

• Use the imperative, present tense (e.g., “change”, not “changed” or “changes”).
• Do not capitalize the first letter.
• Do not end with a period.

Body

• Write in the imperative, present tense.
• Explain the motivation for the change and contrast it with the previous behavior.

Footer

The footer is used for:

• Breaking changes – start with BREAKING CHANGE: followed by a space or two newlines.
• References to GitHub issues that this commit closes (e.g., Closes #123).

Best Practices

• Write meaningful commit messages – clearly convey what changed and why.
• Keep commits small – each commit should represent a single logical change.
• Use branches – create a new branch for each feature or bug fix.
• Squash commits before merging a feature branch to keep history clean.
• Review before committing – ensure code follows project standards and passes tests.
• Automate testing – run automated tests on each commit to catch regressions early.
• Follow a consistent style – adhere to the project’s style guide for uniformity.

References

• FreeCodeCamp. (2022, March 2). How to write better Git commit messages. https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/
• Beams, C. How to write a Git commit message. https://cbea.ms/git-commit/
• 2my. (2021, October 30). Git conventional commits. https://blog.2my.xyz/2021/10/30/git-conventional-commits/