mcpField
G
git-commit-specification

git-commit-specification

github.com/tencentblueking开发2.5k67 次安装2 天前更新
代码仓库

关于 git-commit-specification

面向需要规范 Git 提交的开发者，帮助表达改动意图、选择提交类型并划分提交边界。内容还涵盖提交前的基本检查，不涉及高风险历史操作。

主要功能

  1. 01commit message 编写指导
  2. 02feat、fix 等类型选择
  3. 03提交边界划分
  4. 04提交前基本自检
  5. 05Issue 编号遵循团队约定

适用场景

  1. 01为功能或修复编写提交信息
  2. 02将不同目的的改动拆分提交
  3. 03提交前检查改动范围与敏感信息

安装

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

$npx skills add https://github.com/tencentblueking/bk-ci --skill git-commit-specification

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

详细介绍

来自项目 README

Git 提交规范

适用场景

  • 编写 commit message
  • 判断本次改动应归类为 feat、fix、refactor 等哪一类
  • 整理提交边界，避免一个提交塞入多类无关改动
  • 提交前做最基本的自检

不适用场景

  • 讨论具体业务实现方案
  • 修改 Git 历史或做高风险 Git 操作
  • 只是创建分支，但不涉及提交规范本身

快速指导

  1. 这个 skill 关注的是“提交如何表达改动意图”，不是 Git 命令大全。
  2. commit message 优先表达改动性质和目的，常见类型包括：
    • feat：新增能力
    • fix：修复问题
    • refactor：重构但不改外部行为
    • perf：性能优化
    • test：测试补充或调整
    • docs：文档变更
    • chore：构建、配置、工具链维护
  3. 提交信息格式保持简洁稳定，例如：feat: 添加流水线模板功能 #1234
  4. 一个提交只表达一类主要意图；如果混入多个独立目的，优先拆分提交。
  5. 提交前先做最小自检：改动范围是否聚焦、是否包含敏感信息、是否通过必要验证。
  6. 高风险历史整理操作不应作为默认建议写进主 skill；如确有需要，应按具体场景单独判断。

高信号规则

  • commit message 的核心是让评审者快速理解“这次改动为什么存在”
  • 类型选择要服务于改动意图，不要机械套用
  • 提交边界清楚，比 message 写得花更重要
  • Issue 编号、范围标记等信息应服从团队约定，但不要盖过主语义

关键陷阱

  • 一个提交同时混入功能、重构、修复和格式化
  • message 只写“update”或“fix bug”这类低信息描述
  • 把交互式、破坏性或高风险 Git 操作当成默认规范

延伸阅读

  • 如需准备 PR，可在当前改动基础上补充评审上下文和验证结果
  • 如需处理高风险 Git 历史整理，按具体仓库流程单独判断，不在本 skill 中默认展开

评论

支持 Markdown