How to Write Good Git Commit Messages

Today I learned how to write structure, easy-to-communicate commit messages in Git.

A clear, consistent commit message format helps:

<type>(<scope>): <description>

[optional body]

[optional footer]

Header/Subject (type + scope + description) is required
- Keep the subject line under 72 characters
Body and footer are optional

Type	Description
`feat`	New feature
`fix`	Bug fix
`docs`	Documentation changes
`style`	Formatting, whitespace, etc. (no code change)
`refactor`	Code refactor (no bug fix or feature)
`perf`	Performance improvement
`test`	Adding or updating tests
`chore`	Routine tasks (build, dependencies, etc.)

Example commit messages:

feat(auth): add login with Google OAuth
fix(api): handle token refresh errors
docs(readme): update setup instructions

Tool	What It Does	When It’s Used
commitizen	Interactive CLI that guides you through writing a commit message	Before writing commits
commitlint	Lints commit messages to ensure they meet the standard and enforce consistency ¹	After writing commits
conventional-changelog	Automatically generates changelogs from commit history	After merging/releasing

Example workflow:

Write commits using the Conventional Commits format.
Run npx conventional-changelog -i CHANGELOG.md -s to update your changelog.

This command scans your commit history for Conventional Commits, generates a changelog, writes it to CHANGELOG.md (-i CHANGELOG.md), and updates the file in place (-s). The default preset is Angular, but you can omit -p angular for most projects.

💡 To see all available command line parameters, run: conventional-changelog --help
Optionally, use standard-version or release-it to bump versions and update changelogs automatically.

You can add a Git hook (commit-msg) to validate your commit messages: npx commitlint --edit $1 ↩

Why?