mcpField
G
git

git

github.com/epicenterhq开发4.8k82 次安装2 周前更新
代码仓库

关于 git

指导开发者按 Conventional Commits 编写 Git 提交信息并组织提交的技能，强调一致、原子且便于审查的改动；PR 工作则交由另一项技能说明。

主要功能

  1. 01Conventional Commits 类型与格式
  2. 02可选且具体的范围说明
  3. 03主题行措辞与长度规则
  4. 04破坏性变更标记和版本递增
  5. 05原子提交及正文中的原因说明

适用场景

  1. 01为修复或功能编写提交信息
  2. 02为局部改动选择范围
  3. 03记录破坏性变更及其版本影响

安装

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

$npx skills add https://github.com/epicenterhq/epicenter --skill git

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

详细介绍

Git 提交指南

相关技能：如需让每次提交都便于审查和审计，并将多文件更改按依赖顺序分批处理，请参阅 standalone-commits。有关 PR 标题、描述、变更日志条目、问题引用和合并指南，请参阅 pull-request。

PR 范围

PR 标题、PR 正文、变更日志条目、问题链接、用户名验证、CODEOWNERS 说明和合并策略均属于 pull-request。

参考资料

本技能将规则直接列在文档中。处理 PR 时，请使用 pull-request。

Conventional Commits 格式

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
提交类型
  • feat：新功能（对应语义化版本中的 MINOR）
  • fix：错误修复（对应语义化版本中的 PATCH）
  • docs：仅修改文档
  • refactor：既不修复错误也不添加功能的代码更改
  • perf：性能改进
  • test：添加或修改测试
  • chore：维护任务、依赖更新等
  • style：代码风格更改（格式调整、缺少分号等）
  • build：构建系统或依赖项更改
  • ci：CI 配置文件和脚本更改
范围指南
  • 范围是可选的：仅在有助于明确说明时添加
  • 使用小写，并放在类型后面的括号中：feat(transcription):
  • 优先使用具体的组件／模块名称，而非泛泛的术语
  • 当前做法很好：使用组件名称（EditRecordingDialog）、功能领域（transcription、sound）
  • 避免使用 ui 或 backend 等过于泛泛的范围，除非确实合适
何时使用范围
  • 更改仅涉及特定组件／模块时
  • 有助于区分相似更改时
  • 在领域划分明确的大型代码库中工作时
何时不使用范围
  • 更改对多个领域的影响相当时
  • 仅靠类型就足以描述更改时
  • 更改较小且一目了然时
描述规则
  • 冒号和空格后立即以小写字母开头
  • 使用祈使语气（用 "add"，而不是 "added" 或 "adds"）
  • 末尾不加句号
  • 首行控制在 50-72 个字符以内
破坏性更改与版本递增

我们的单体仓库采用统一的版本方案（8.Y.Z），主版本号 8 固定不变：

  • Patch（默认）：每个合并的 PR 都会递增 Z（例如，8.0.1 → 8.0.2）
  • Minor：在类型／范围后添加 !：feat(api)!: change endpoint structure，递增 Y 并将 Z 重置
  • Major：仅手动递增。仅在“确有需要时”使用。不要使用 ! 来期待主版本号递增。

使用 ! 时，请在提交页脚中添加 BREAKING CHANGE: 并说明详情。

符合当前风格的示例：
  • feat(transcription): add model selection for OpenAI providers
  • fix(sound): resolve audio import paths in assets module
  • refactor(EditRecordingDialog): implement working copy pattern
  • docs(README): clarify cost comparison section
  • chore: update dependencies to latest versions
  • fix!: change default transcription API endpoint

提交信息最佳实践

“原因”比“内容”更重要

提交信息的主题行描述更改了什么，正文解释为什么更改。

良好的提交（说明动机）：

fix(auth): prevent session timeout during file upload

Users were getting logged out mid-upload on large files because the
session refresh only triggered on navigation, not background activity.

不好的提交（只描述更改内容）：

fix(auth): add keepalive call to upload handler

第一条提交信息能告诉未来的开发者代码存在的原因。第二条则会让他们不得不翻阅代码才能理解其用途。

其他最佳实践
  • 绝不包含 Claude Code 或 opencode 的水印或署名
  • 每次提交都应代表一个独立、原子化的更改
  • 为未来的开发者（包括你自己）编写提交信息
  • 如果需要用多行才能描述所做的更改，请考虑拆分提交

不应包含的内容：

  • Generated with [Claude Code](https://claude.ai/code)
  • Co-Authored-By: Claude <[email protected]>
  • 任何提及 AI 助力的内容
  • Generated with [opencode](https://opencode.ai)
  • Co-Authored-By: opencode <[email protected]>
  • 工具署名或水印

评论

支持 Markdown