28

Git Commit 规范与 Emoji

⏱️ 10分钟

Git Commit 规范与 Emoji

为什么需要 Commit 规范?

好的 Commit 信息能够:

  • 快速理解每次变更的目的
  • 自动生成 Changelog
  • 方便代码审查和回溯
  • 让团队协作更高效

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

如果你想快速提交,可以使用这个流程:

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

这在你确定改动很清晰的情况下非常有用。

Pre-commit Checks

建议在提交前运行:

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

可以使用 husky 配置 pre-commit hooks 自动运行这些检查。

下一步

学习 五个为什么分析法 来深入分析问题根因。

📚 相关资源

❓ 常见问题

关于本章主题最常被搜索的问题,点击展开答案

Conventional Commits 里常用的 type 都有哪些?

本章列了 12 种带 emoji 的类型:✨ feat(新功能)、🐛 fix(bug)、📝 docs、♻️ refactor、🎨 style、⚡️ perf、✅ test、🧑‍💻 chore、🚧 wip、🔥 remove、🚑 hotfix、🔒 security。日常 80% 的 commit 落在 feat / fix / refactor / docs 这 4 个,其它按需用,不用强行凑。

Commit message 用现在时还是过去时?

祈使句(imperative mood),写 "Add feature" 不写 "Added feature"。理由:Git 自己生成的 message(merge / revert)就用祈使句,跟它对齐 PR 列表读起来才一致;另外祈使句更短,放在 `type(scope): description` 50 字符限制里更宽裕。

什么时候该写 commit body?什么时候 subject 一行就够?

改动 "为什么" 显而易见就一行 subject 够了(typo 修复、依赖升级、格式调整);改动有非显然的取舍、引用了 issue、影响别的模块就要加 body。模板:subject 写 what,body 解释 why + trade-off + refs(Closes #123)。Body 段落空一行隔开,不写废话。

Pre-commit hook 应该跑哪些检查?

三件事按顺序跑:(1) Linting — ESLint / Prettier 自动修可修的;(2) Type check — `tsc --noEmit` 抓掉静态错误;(3) Unit tests — 只跑改动文件相关的,全跑会让 commit 等到天荒地老。用 husky + lint-staged 配置,确保只对 staged file 跑,不影响干净的代码。

AI 自动生成 commit message 比手写好用吗?

看场景。改动清晰、scope 单一时,AI 生成 3 个候选 + 自动选第一个的 fast workflow 比手写快 5-10 倍,质量也够;改动跨多 module 或包含设计决策时,AI 写不出 "为什么选 A 不选 B" 的 body,必须人补。建议:让 AI 草稿 subject,body 自己写。