Git Commit Conventions & Emoji
Git Commit Conventions & Emoji
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
| Emoji | Type | Description |
|---|---|---|
| ✨ | feat | New features |
| 🐛 | fix | Bug fixes |
| 📝 | docs | Documentation changes |
| ♻️ | refactor | Code restructuring without changing functionality |
| 🎨 | style | Code formatting, missing semicolons, etc. |
| ⚡️ | perf | Performance improvements |
| ✅ | test | Adding or correcting tests |
| 🧑💻 | chore | Tooling, configuration, maintenance |
| 🚧 | wip | Work in progress |
| 🔥 | remove | Removing code or files |
| 🚑 | hotfix | Critical fixes |
| 🔒 | security | Security improvements |
Commit Process
- Check for staged changes (
git status) - If no staged changes, review and stage appropriate files
- Run pre-commit checks (unless --no-verify)
- Analyze changes to determine commit type
- Generate descriptive commit message
- Include scope if applicable:
type(scope): description - Add body for complex changes explaining why
- 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:
- Stage all changes:
git add . - Generate 3 commit message suggestions
- 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.
📚 相关资源
❓ 常见问题
关于本章主题最常被搜索的问题,点击展开答案
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 自己写。