mcpField
C
conventional-commits

conventional-commits

github.com/lelborn开发047 次安装2 周前更新
代码仓库

关于 conventional-commits

一项指导开发者按实际改动编写机器可读 Conventional Commits 的技能，涵盖提交格式、SemVer 影响及变更日志整理。

主要功能

  1. 01根据差异选择提交类型
  2. 02说明标题、作用域、正文和页脚格式
  3. 03标记不兼容变更
  4. 04检查提交信息格式
  5. 05提供变更日志分类建议

适用场景

  1. 01为代码改动撰写提交信息
  2. 02标记不兼容的 API 变更
  3. 03检查提交信息格式问题

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/lelborn/skills --skill conventional-commits

安装后在 Claude Code 中输入/conventional-commits确认已加载。

详细介绍

Conventional Commits

按照 Conventional Commits v1.0.0 的规范格式化提交消息，使其包含机器可读的含义。规范的提交历史能让工具递增 SemVer 版本并生成变更日志，也能让读者无需打开差异即可浏览 git log——但前提是每次提交都遵循该格式，因此应默认采用，而不是等别人要求。

格式

<type>[optional scope][!]: <description>

[optional body]

[optional footer(s)]

只要求填写标头；docs: fix typo in readme 就是一个完整且有效的提交。

类型——根据差异，而不是请求

根据改动_做了什么_来选择类型，而不是根据用户_怎么称呼_它。“清理登录页面”可能属于 fix、refactor 或 style；在决定前先查看 git diff --staged。

类型用途SemVer
feat新功能MINOR
fix修复错误PATCH
docs仅文档—
style格式调整，不改变代码含义—
refactor既不修复错误，也不添加功能—
perf性能改进—
test添加或修复测试—
build构建系统、工具、依赖—
ciCI 配置和脚本—
chore维护性工作，不涉及 src 或测试—
revert撤销之前的提交—

feat/fix 涉及用户可见的行为；refactor 仅涉及内部实现。如果一个差异涉及多种类型，这说明应该将改动拆分为每个逻辑改动一个提交，而不是强行用一种类型涵盖所有内容。撤销提交时，使用 revert，并在页脚中注明被撤销提交的 SHA（Refs: 676104e）。

字段

  • 范围——用括号括起的可选名词，表示受影响的领域（fix(auth):）。当改动仅涉及一个模块/组件时添加；范围名称应与现有历史保持一致。
  • 描述——使用祈使语气（“add”，而不是“added”/“adds”），不超过约 72 个字符，全部小写，不加句末句号，并且要具体：fix: handle empty array in parseArgs 优于 fix: bug。
  • 正文——可选，与描述之间空一行。解释_原因_；不要逐行叙述差异。仅在原因不明显时添加。
  • 页脚——可选，与正文之间空一行。格式为 Token: value 或 Token #123；标记中的空格用 - 替代（Reviewed-by、Co-authored-by）。只有在掌握相关信息时才添加——不要捏造问题编号或审阅者。

破坏性变更

破坏性变更会迫使使用者修改其代码，例如删除/重命名 API、更改默认值或改变响应结构。用以下一种或两种方式标记：

  • 在冒号前加 !：feat(api)!: drop support for legacy tokens
  • 添加页脚：BREAKING CHANGE: <what breaks and how to migrate>

无论类型如何，它都属于 SemVer MAJOR 变更（fix! 仍然是破坏性变更）。如果迁移方式不明显，建议添加页脚。除 BREAKING CHANGE（同义写法为 BREAKING-CHANGE）外，所有内容都不区分大小写；这两种写法必须使用大写。

示例

feat(lang): add Polish translation

fix: prevent racing of requests

Introduce a request id and dismiss responses from any but the latest request.

Refs: #123

feat(api)!: send an email when a product ships

BREAKING CHANGE: the shipment webhook no longer includes the deprecated
`email_sent` flag; read shipment state from `status` instead.

检查消息

标记以下问题：缺少类型或类型后缺少 :；描述为空或未紧跟在前缀后；正文/页脚未用空行分隔；页脚标记中包含空格（BREAKING CHANGE 除外）；BREAKING CHANGE 未使用大写；破坏性差异没有标记；类型与差异不匹配。

根据历史生成 CHANGELOG

按类型分组（feat → 功能、fix → 修复……），无论类型如何，都将带有破坏性标记的内容列在 BREAKING CHANGES 下；省略没有面向用户意义的类型（chore、style、ci……），除非用户希望查看完整历史。配套的 keep-a-changelog 技能对此有深入介绍。

评论

支持 Markdown