How to write good commit messages in Git?

A good commit message helps the team understand history and simplifies debugging. Here are rules and practices.

Message structure: the first line is a brief summary, no more than 50 characters, in the imperative mood: "Add registration form validation", not "Added validation". After a blank line — a detailed description: what changed and why, not how (the code shows how). Description — up to 72 characters per line.

Conventional Commits — a popular formatting standard. Format: type(scope): description. Types: feat (new feature), fix (bug fix), docs (documentation), style (formatting), refactor (refactoring), test (tests), chore (maintenance), perf (performance), ci (CI configuration). Example: feat(auth): add OAuth2 authorization via Google. This allows automatic changelog generation and version management.

Practical rules: one commit — one logical change. Don't mix refactoring and a new feature in one commit. If a change touches multiple files but they're all part of one task — that's one commit. Commit often — small commits are easier to revert and review.

What to avoid: messages like "fix", "update", "wip", "misc changes". The message "fix bug" says nothing — which bug, where, how. Better: "fix(cart): fix total calculation with empty promo code". Don't write messages in past tense — "added" instead of "add".

Multi-line messages: use git commit without -m — an editor will open. Or multiple -m flags: git commit -m "short summary" -m "detailed description in second paragraph".

Pre-commit check: git diff --cached shows staged changes. Review them before committing to avoid accidentally including debug code or temporary files.