Clear, consistent commit messages make project history easier to read, reason about, and revert when necessary.
Practical guidelines and examples for writing concise, informative Git commit messages that improve collaboration and maintainability.
Why good commit messages matter
Good commit messages explain the intent behind a change, not just what changed. They help reviewers understand design decisions, make bisecting and debugging easier, and provide valuable context when reading project history months or years later.
Recommended structure
Use a short subject line (50 characters or less) in the imperative mood, followed by a blank line and a more detailed body wrapped at about 72 characters. The subject summarizes the change; the body explains why the change was made and any trade-offs or side effects.
Concrete best practices
Write the subject in present tense and imperative mood (e.g., "Fix memory leak"). Keep the subject brief and capitalized without a trailing period. When needed, include a body that answers what, why, and how. Reference relevant issue IDs or pull request numbers. Avoid mixing unrelated changes in a single commit.
Examples
Good subject: "Optimize image loading for gallery view". With body: "Reduce memory usage by decoding thumbnails lazily. This avoids loading full images into memory on initial render and fixes OOMs on low-end devices. Closes #412." Bad subject: "Fixed stuff" or "Changes".
Tooling to help
Use commit message templates, linters (commitlint), and interactive tools like Commitizen or git hooks (husky) to enforce a consistent style. Automated checks help keep messages readable and machine-parsable for changelogs.