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.
