git-commit-zh

name	git-commit-zh
description	基于当前仓库改动生成 Conventional Commits 风格的提交信息。用于编写、改写、审核 commit message；从暂存/未暂存 diff 推断 type、scope、subject 和可选 body，避免套模板。
argument-hint	说明是暂存还是未暂存改动，或补充范围/约束

Git Commit (中文)

概览

根据真实的仓库改动生成提交信息。优先写清楚本次提交的核心意图，不要逐文件复述 diff。 参考 commit 规范 的基本格式与示例，具体 scope 和措辞必须结合当前仓库推断。

适用场景

• 需要从当前改动生成提交信息
• 需要改写或审阅已有的提交信息
• 需要把提交信息对齐到 Conventional Commits 风格

工作流程

1. 先检查改动集。
   • 有暂存改动时，优先看 git diff --staged。
   • 没有暂存改动，或用户明确要求查看未暂存改动时，看 git diff。
   • 用 git status --short 判断改动范围。
   • 如果仓库有自己的提交规范，先读取它。常见文件包括 COMMIT_CONVENTION.md、CONTRIBUTING.md、.github/COMMIT_CONVENTION.md、.github/CONTRIBUTING.md。
   • 查看最近的提交标题（git log --format=%s -n 20）判断仓库惯用风格与语言。
2. 选择一个提交意图。
   • 如果改动包含多个无关意图，建议拆分提交。
   • 如果用户仍要求合并为一个提交，选择主导意图，并简短说明取舍。
3. 生成 header：

<type>(<scope>): <subject>

4. 只有在需要说明意图、影响面、兼容性、迁移背景或混合改动类型时才添加 body。

Type 选择

• feat：新增功能
• fix：修复问题或缺陷
• perf：性能优化
• refactor：重构实现但不改变外部行为
• style：格式、代码风格调整，不影响运行结果
• test：测试补充或调整
• docs：文档或注释更新
• chore：依赖、构建、脚手架、杂项维护
• ci：持续集成相关调整
• types：类型定义变更
• revert：撤销已有提交
• wip：开发中临时提交

混合改动优先建议拆分提交；如果必须合并，header 使用主导类型，并在 body 的条目里用 type: 标注不同类型。

Scope 选择

从当前仓库推断 scope。不要复用参考文件里的 scope，除非它们确实匹配当前改动路径或仓库规范。

选择优先级：

1. 优先使用当前仓库提交规范中明确定义的 scope。
2. 其次从改动路径中提取稳定的 workspace、package、app 或模块名，例如 api、web、cli、core、ui、docs，或具体包名。
3. 如果改动集中在更明确的子模块，可以使用更细粒度且可长期复用的 scope。
4. 跨多个模块、仓库级配置、或无法归一到单一模块的改动使用 repo。

如果当前仓库规范允许无 scope，且没有有意义的模块范围，可以省略 scope。

Subject 和 Body

• subject 直接写本次修改的核心意图，保持简洁、具体、偏动作。避免 update、fix bug、optimize code 这类空泛标题。
• 输出语言优先遵循仓库规范；若无明确规范但历史提交存在主导语种，则沿用该语种；两者都无法判断时，默认中文。
• 需要 body 时：
  • 说明修改意图、影响面和必要背景。
  • 不要逐文件复述 diff。
  • 如果所有条目属于同一种修改类型，不要在每条里重复 type。
  • 如果一次提交包含不同类型的改动，在 body 条目前加 type:。

示例：

feat(auth): 增加会话刷新流程

- 增加会话刷新入口，减少登录态过期后的重复认证
- 补齐旧 token 兼容逻辑，避免升级后状态丢失

refactor: 统一发布流程

- refactor: 收敛构建与发布脚本的职责边界
- fix: 修正缺少版本号时的默认值异常
- docs: 补充新的发布流程说明

参考

阅读 commit 规范 了解 Conventional Commits 的基础格式与示例。实际 scope 与措辞必须以当前仓库为准。