gitmoji

Gitmoji

生成遵循 gitmoji 约定的提交信息：每次提交都以一个 emoji 开头，让人一眼看出本次变更的意图。给定一个 diff、一份已暂存文件列表，或对某项变更的纯文字描述，本技能会挑选出唯一最合适的 gitmoji，并围绕它写出简洁、规范的提交信息。

本技能只生成提交信息——它绝不会运行 git commit 或任何其他 git 命令。输出的是可供用户复制使用的提交信息。

何时使用本技能

• 用户说“写一个 gitmoji 提交”“给这次变更加上 gitmoji”或“在我的提交信息里加个 emoji”
• 用户问“这个我该用哪个 gitmoji？”
• 用户粘贴了一段 git diff，或描述了一个使用 gitmoji 风格提交历史的项目中的某项变更
• 用户希望得到一份富有表现力、便于浏览的 emoji 提交历史

**何时不使用：**如果项目遵循不带 emoji 的纯 Conventional Commits（feat:、fix:……），请改用 conventional-commit 或 commit-message-storyteller 技能。如果不确定项目使用哪种约定，请让用户提供最近的提交历史（例如 git log --oneline -10 的输出）。

提交信息格式

gitmoji 规范：

<intention> [scope?][:?] <message>

• intention —— 恰好一个 gitmoji，表达本次提交的目标
• scope （可选）—— 受影响的代码库部分
• message —— 对本次变更的简短祈使式说明

示例：

✨ add multi-tenant support to the billing service
🐛 (auth) prevent token refresh loop on expired sessions
♻️ (api): extract pagination logic into shared helper

Emoji 风格：Unicode 与短代码

Gitmoji 支持两种等效的写法：

风格	示例	何时优先使用
Unicode	✨ add dark mode	默认 —— 随处都能渲染，主题行更短
短代码	:sparkles: add dark mode	能渲染短代码的平台（GitHub、GitLab），或按代码检索提交日志的团队

**与仓库的现有历史保持一致。**如果最近的提交使用 :sparkles: 这类短代码，就生成短代码；否则默认使用 unicode emoji。

工作原理

第 1 步：理解变更

根据用户提供的内容开展工作：

1. 一段 git diff —— 阅读它，弄清改了什么以及为什么改
2. 一份已暂存/已修改文件列表 —— 从文件名和路径推断意图
3. 一段纯文字描述 —— 直接使用它

如果意图确实含糊不清（例如“更新了 auth.js”可能是修复、新功能或重构），请提出一个简短的澄清问题，而不是猜测。

第 2 步：识别主导意图

确定本次变更的主要目的。常见意图及其对应的 gitmoji：

Emoji	短代码	意图
✨	:sparkles:	引入新功能
🐛	:bug:	修复 bug
🚑️	:ambulance:	紧急热修复
📝	:memo:	添加或更新文档
♻️	:recycle:	重构代码（不改变行为）
✅	:white_check_mark:	添加、更新或通过测试
⚡️	:zap:	提升性能
🎨	:art:	改进代码结构 / 格式
🔥	:fire:	删除代码或文件
🔒️	:lock:	修复安全或隐私问题
⬆️	:arrow_up:	升级依赖
🔧	:wrench:	添加或更新配置文件
💄	:lipstick:	添加或更新 UI 和样式文件
💥	:boom:	引入破坏性变更
🚨	:rotating_light:	修复编译器 / linter 警告
🌐	:globe_with_meridians:	国际化与本地化

这只是最常见的子集——在最终确定之前，请务必查阅 references/gitmoji-reference.md 以获取全部 75 个官方 gitmoji 的完整列表；往往存在更贴切的 emoji（例如 🩹 表示琐碎修复，✏️ 表示拼写错误，🚚 表示文件移动）。

第 3 步：只选择一个 Emoji

模糊情况的规则：

• 具体优于笼统 — 错别字修正用 ✏️，而不是 🐛；移动文件用 🚚，而不是 ♻️；不关键的小修复用 🩹，而不是 🐛
• 测试： 添加/更新通过的测试用 ✅；只有故意失败的测试（例如 TDD 的 red 步骤）才用 🧪
• Fix 与 hotfix： 🚑️ 仅用于紧急的生产修复；日常 bug 修复用 🐛
• 安全修复： 当 bug 属于安全问题时，🔒️ 优先于 🐛
• 仅格式变更： 代码结构/格式用 🎨；只有 UI/样式文件（CSS、主题）才用 💄
• 每个提交一个 emoji — 绝不要叠加 emoji；如果两种意图看起来同样占主导，请参阅下方的混合变更

第 4 步：编写提交信息

• 使用祈使语气："add"、"fix"、"remove" — 而不是 "added" 或 "fixes"
• 主题行（包括 emoji）保持在 72 个字符以内
• 首字母小写，结尾不加句号
• 当项目历史使用 scope 时，在括号中添加 scope
• 仅当从主题看不出原因时，才添加正文（用空行分隔）

第 5 步：输出

在可复制的代码块中生成提交信息，后跟一行说明为何选择该 gitmoji。请不要执行 git commit。

示例输出：

🐛 (auth) prevent token refresh loop on expired sessions

Expired sessions triggered a refresh that failed validation and
re-triggered itself, crashing the app. A recursion guard now aborts
the cycle and returns a clean 401.

为何选择 🐛： 该变更修正了不正确的运行时行为 — 这是 bug 修复，尚未紧急到需要使用 🚑️。

边缘情况

情况	处理方式
混合变更（例如一个 diff 中同时包含功能和重构）	为占主导的意图选择 emoji，如果这些关注点不相关，建议拆分为多个独立提交
破坏性变更	使用 💥 作为意图，并在正文中描述破坏之处
回滚	⏪️，主题中引用被回滚的提交
合并提交	🔀 merge branch '<name>' into <target>
初始提交	🎉 begin project
进行中的工作	🚧，并清楚注明剩余事项
没有合适的 emoji	重新查看完整参考；如果仍没有合适的，退回到最接近的通用意图（✨、🐛 或 ♻️）

快速参考

# Get your staged diff to paste into Copilot
git diff --staged

# Check which emoji style the repo already uses
git log --oneline -10

完整的官方 gitmoji 列表请参见 references/gitmoji-reference.md。