Commits规范

1. Commit 类型选择

1.1 常用类型（Conventional Commits + Gitmoji）

type	emoji	含义	典型场景
feat	✨	新功能	新增按钮、抽奖功能等
fix	🐛	Bug 修复	移动端元素溢出、按钮不可点击
style	💄	样式/格式调整，不改逻辑	CSS 改动、排版调整、移动端适配（视觉改善）
refactor	♻️	重构，不改变功能	提取 SCSS mixin、优化样式结构
perf	⚡	性能优化	减少渲染次数、图片懒加载
docs	📝	文档	README、注释
chore	🔧	构建/工具/发布	发布提交、版本号更新
test	✅	测试	新增/修改测试代码

✅ 原则：Commit type 看“改变的语义”，不是文件类型。
CSS 改“长相” → style
CSS 改“写法/组织方式” → refactor
修复用户感知 bug → fix

1.2 BREAKING CHANGE

当接口或功能不兼容升级时，用 ! 或 body 标记：

feat(api)!: 统一接口返回 R<T>
BREAKING CHANGE: 接口返回结构由原始数据改为 R<T>

判断口诀：

“有人只升级一半会出错？” → YES → BREAKING

注意：用户感知无关紧要，关键看依赖方是否要改代码。

1.3 Scope（模块）

scope 说明“业务模块”，不是技术栈：

对：pick、ui、api

不要写：frontend、backend

body 可以补充技术实现或修复细节。

2. Emoji 使用

作用：快速扫读、视觉提示，不影响工具解析

推荐常用：

🐛 fix
✨ feat
💄 style
♻️ refactor
🚀 chore(release)

不要乱造 type，emoji 仅装饰。

3. 什么时候拆提交

原则

一个 commit 只解决一个主语义问题
fix 保持最小 diff → 方便回顾 / cherry-pick / 排查 bug
重构、样式、功能不能混在一个 commit

常见场景拆法

场景	拆分方法
重构 SCSS + 修复溢出	1. refactor(scss) 2. fix(ui)
写新 UI + 功能逻辑	1. style/ui 2. feat/logic
多子命令接口迁移	每个子命令单独提交 BREAKING

4. CHANGELOG 自动生成

工具

conventional-changelog

standard-version

semantic-release

原则

只关心 feat / fix / BREAKING CHANGE

emoji 不影响

body 可写技术细节，但 summary 作为 CHANGELOG 条目。

5. 版本号 & 发布

5.1 版本号规则（SemVer）

MAJOR.MINOR.PATCH

MAJOR: BREAKING CHANGE

MINOR: 新功能、向下兼容

PATCH: Bug 修复

0.x 阶段：

MINOR 和 PATCH 可快速迭代

BREAKING 也会升级 MINOR 或 MAJOR 视策略

5.2 发布提交

原则：发布提交通常独立，不与功能或 fix 混在一起

🎉 chore(release): v0.2.0

✅ emoji 可选，放前面完全 OK

❌ 不要用 release: 作为 type（不标准，工具可能忽略）

CHANGELOG 会识别 chore(release) 提交时自动更新版本号

5.3 发布流程（推荐）

业务/功能提交（feat / fix / refactor / style）

生成/更新 CHANGELOG

创建发布提交：

🎉 chore(release): vX.Y.Z

打 tag 并推送

发布到 npm / GitHub Release

6. 判断 fix vs style vs refactor 口诀

类型	判断核心
fix	用户/功能无法正常使用，实际 bug
style	不影响行为，只改变视觉/排版
refactor	不改变功能，但代码结构/可维护性优化

“CSS 改长相 → style
CSS 改写法 → refactor
CSS 修 bug → fix”

7. Mixed Commit 决策优先级

一个 commit 最多只能有一个主语义

优先级（高 → 低）
BREAKING CHANGE
fix
feat
refactor
style

原则：用户可感知的变化 > 功能 > 重构 > 样式

8. 工程师思维核心

Commit 是给未来维护者看的“最小证据”，不是保存快照

Scope 说明模块，body 补充技术细节

emoji 仅作视觉辅助，不影响工具

BREAKING 关注依赖方，用户感知可忽略

fix 保持最小 diff → 易回溯、复用、cherry-pick

9. 常用 commit 模板示例

修 bug

🐛 fix(pick): 修复移动端元素溢出导致按钮无法点击

重构样式

♻️ refactor(scss): 使用 mixin 重构重复样式

样式微调 / 移动端适配

💄 style(ui): 优化抽奖页面移动端布局

发布

🎉 chore(release): v0.2.0

✅ 总结一句话：

Commit = 记录语义，最小 diff，方便回溯
Release = 单独提交，type 用 chore(release)
Scope = 模块，emoji = 装饰，BREAKING = 技术契约变化

1. Commit 类型选择#

1.1 常用类型（Conventional Commits + Gitmoji）#

1.2 BREAKING CHANGE#

1.3 Scope（模块）#

2. Emoji 使用#

3. 什么时候拆提交#

原则#

常见场景拆法#

4. CHANGELOG 自动生成#

工具#

原则#

5. 版本号 & 发布#

5.1 版本号规则（SemVer）#

5.2 发布提交#

5.3 发布流程（推荐）#

6. 判断 fix vs style vs refactor 口诀#

7. Mixed Commit 决策优先级#

8. 工程师思维核心#

9. 常用 commit 模板示例#

修 bug#

重构样式#

样式微调 / 移动端适配#

发布#