Chapter 28
28 / 38

Git Commit Conventions & Emoji

⏱️ 10 min

Why Have Commit Conventions?

Good commit messages let you:

  • Quickly understand the purpose of each change
  • Auto-generate changelogs
  • Make code review and git blame easier
  • Keep team collaboration efficient

Commit Message Format

type(scope): description

[optional body]

[optional footer]

Commit Types with Emoji

EmojiTypeDescription
featNew features
🐛fixBug fixes
📝docsDocumentation changes
♻️refactorCode restructuring without changing functionality
🎨styleCode formatting, missing semicolons, etc.
⚡️perfPerformance improvements
testAdding or correcting tests
🧑‍💻choreTooling, configuration, maintenance
🚧wipWork in progress
🔥removeRemoving code or files
🚑hotfixCritical fixes
🔒securitySecurity improvements

Commit Process

  1. Check for staged changes (git status)
  2. If no staged changes, review and stage appropriate files
  3. Run pre-commit checks (unless --no-verify)
  4. Analyze changes to determine commit type
  5. Generate descriptive commit message
  6. Include scope if applicable: type(scope): description
  7. Add body for complex changes explaining why
  8. Execute commit

Best Practices

  • Keep commits atomic and focused
  • Write in imperative mood ("Add feature" not "Added feature")
  • Explain why, not just what
  • Reference issues/PRs when relevant
  • Split unrelated changes into separate commits

Examples

Feature Addition

git commit -m "✨ feat(auth): add OAuth2 login support

- Implemented Google OAuth2 provider
- Added token refresh mechanism
- Updated user session handling

Closes #123"

Bug Fix

git commit -m "🐛 fix(api): handle null response in user endpoint

The API was crashing when user data was incomplete.
Added null checks and default values.

Fixes #456"

Documentation

git commit -m "📝 docs: update API documentation for v2 endpoints"

Refactoring

git commit -m "♻️ refactor(utils): extract validation logic to separate module"

Fast Commit Workflow

For quick commits when the change is clear-cut:

  1. Stage all changes: git add .
  2. Generate 3 commit message suggestions
  3. Auto-select the first one

This works well when you're confident the change is straightforward.

Pre-commit Checks

Run these before committing:

  • Linting (ESLint, Prettier)
  • Type checking (TypeScript)
  • Unit tests

You can use husky to set up pre-commit hooks that run these checks automatically.

Next Steps

Check out Five Whys Analysis for root cause debugging.

📚 Related resources

Common questions

Open a question to review the practical answer.

Which commit types does the convention cover?

The chapter lists 12 emoji-tagged types: ✨ feat (new feature), 🐛 fix (bug), 📝 docs, ♻️ refactor, 🎨 style, ⚡️ perf, ✅ test, 🧑‍💻 chore, 🚧 wip, 🔥 remove, 🚑 hotfix, 🔒 security. About 80% of daily commits land in feat / fix / refactor / docs — use the others when they fit, do not force-fit.

Should commit messages be present tense or past tense?

Imperative mood — write "Add feature" not "Added feature". Reason: Git's own generated messages (merge / revert) use imperative, so matching it keeps the PR list visually consistent; imperative also runs shorter, leaving room inside the 50-char `type(scope): description` budget.

When do I need a commit body and when is a one-line subject enough?

If the "why" is obvious from the diff (typo fix, dependency bump, formatting), a single subject line is enough; if there is a non-obvious trade-off, an issue reference, or cross-module impact, add a body. Template: subject = what, body = why + trade-off + refs (Closes #123). Separate body paragraphs with a blank line, no filler.

What checks belong in a pre-commit hook?

Three things in order: (1) Linting — ESLint / Prettier auto-fix what can be fixed; (2) Type check — `tsc --noEmit` to catch static errors; (3) Unit tests — only the ones touching changed files, running the whole suite makes every commit drag forever. Wire it with husky + lint-staged so it scopes to staged files and leaves clean code untouched.

Is letting AI generate commit messages better than writing them by hand?

Depends on the change. For clean, single-scope diffs, the fast workflow (AI drafts 3 candidates, auto-pick first) beats hand-writing 5-10x and quality is fine; for cross-module changes or design decisions, AI cannot write the "why A not B" body, you have to. Compromise: let AI draft the subject, write the body yourself.