mcpField
C
commit-messages

commit-messages

github.com/streamofron开发071 次安装3 周前更新
代码仓库

关于 commit-messages

为编写、修改和审查 Git 提交说明提供规范的技能，面向需要清晰传达变更意图的开发者。它强调简洁的祈使式标题，并在需要时用正文说明原因和背景。

主要功能

  1. 01撰写简洁的提交标题
  2. 02采用祈使语气并概括变更
  3. 03按需添加说明正文
  4. 04控制正文行宽并引用问题
  5. 05检查提交信息质量

适用场景

  1. 01为新变更编写提交信息
  2. 02压缩或变基时改进提交说明
  3. 03审查提交信息是否清晰

安装

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

$npx skills add https://github.com/streamofron/agent-skills --skill commit-messages

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

详细介绍

提交消息

编写清晰、简洁的提交消息，让读者一眼了解提交意图的指南。

适用场景

  • 为新更改编写提交消息
  • 合并或变基提交
  • 检查提交消息是否清晰

**不适用于：**标签消息、自动化工具生成的合并提交消息或变更日志条目。

流程

  1. 编写简洁的主题行——这是大多数人看到的第一行：

    • 建议不超过 160 个字符；越短越好
    • 使用祈使语气：“Add feature”，而不是 “Added” 或 “Adds”
    • 首字母大写；末尾不加句号
    • 概述更改内容，而不是更改过程

  2. 在主题和正文之间空一行——这是工具正确解析所必需的。如果主题本身已足够清楚，则省略正文。

  3. 需要补充背景时编写正文——解释为什么，而不是是什么：

    • 每行约 72 个字符
    • 说明更改的动机；解释限制条件或决策
    • 使用 Fixes #123 或 Refs #456 引用问题

  4. 每个提交只包含一个逻辑更改——如果消息需要用 “and” 来描述更改，那么它可能应该拆分成两个提交。

应包含的内容

  • 高层概述更改了什么
  • 为什么进行更改（尤其是在正文中）
  • 破坏性更改或迁移说明（如有）
  • 适用时添加问题引用

不应包含的内容

  • 文件列表——git diff 和 git show 已经会显示这些内容
  • 含糊的描述——“fix bug”“update stuff”“WIP”
  • 多个无关更改——拆分成单独的提交
  • 实现细节——差异会说明如何实现；消息应解释原因

常见问题

  • 主题含糊：“fix bug”什么也没告诉读者。应指出具体的错误或修复内容。
  • 使用过去时：“Added feature”读起来像日记。使用祈使语气：“Add feature”。
  • **主题过长：**超过 160 个字符后，在大多数视图中都会被截断。保持简洁易读。
  • **主题后没有空行：**会导致工具出现问题（git log --oneline、GitHub、变更日志）。
  • **巨型提交：**如果消息长得像篇小说，那么提交内容就太多了。拆分提交。
  • **消息中包含注释掉的代码：**不要把差异或代码粘贴到消息正文中。

验证

编写提交消息后，确认：

  • 主题少于 160 个字符，并概述更改
  • 使用祈使语气（“Fix”“Add”“Update”）
  • 主题和正文之间有空行（如果有正文）
  • 正文解释为什么，而不是是什么
  • 每个提交只包含一个逻辑更改

快速检查清单：

Is the subject under 160 characters?
Does it use imperative mood?
Is there a blank line after the subject?
Does the body explain why (if present)?
Could this commit be split into smaller ones?

评论

支持 Markdown