git-commit-only-cn

name	git-commit-only-cn
description	当用户只需要创建一个本地 Git 提交且不推送时使用。支持基于 diff 自动判断 Conventional Commit 的 type/scope/summary、处理已暂存或用户要求的改动范围、为非简单改动生成分段提交正文，并执行安全的仅提交工作流。适用于“提交当前改动”“只 commit 不 push”“创建一个本地提交”等请求。

Git 仅提交

Overview

从当前仓库已暂存或用户要求的改动中，创建一个聚焦的本地 Conventional Commit，不推送到任何远端。

默认结果是在当前分支上生成一个提交。需要分析实际 diff，暂存用户要求的改动范围，根据改动内容生成提交信息；对于非简单改动，需要写分段提交正文，让评审者能按主题快速理解改动内容。

这个流程只处理本地提交请求；不推送、不合并分支、不改写历史、不创建 PR、不发布改动。

Conventional Commit 规则

基础格式：

<type>[可选 scope]: <description>

[正文：仅简单改动可省略；非简单改动必须写分段正文]

[footer：破坏性变更必须填写；相关 issue 引用可按需填写]

在本技能中，正文只对简单提交可选。非简单改动必须写分段正文；如果运行了测试、校验、hook 或手动验证，必须包含“测试：”或“验证：”等价分段。

类型：

Type	用途
feat	新增用户可见或产品能力
fix	修复 bug
docs	仅文档变更
style	不影响逻辑的格式或样式变更
refactor	不新增功能、不修 bug 的代码重构
perf	性能优化
test	测试或覆盖率变更
build	构建系统、依赖或打包变更
ci	CI 或自动化配置变更
chore	维护或杂项变更
revert	回滚历史提交

破坏性变更：

• 在 type 或 scope 后使用 !，例如 feat(api)!: 移除旧字段。
• 行为契约发生变化时，在 footer 中加入 BREAKING CHANGE:。

提交信息风格：

• 使用仓库既有的提交语言。
• 标题使用现在时和祈使语气，例如 fix login redirect 或 修复登录跳转。
• 标题尽量控制在 72 个字符以内。
• 相关时在正文或 footer 中引用 issue，例如 Closes #123 或 Refs #456。

何时使用

当用户要求执行以下操作时使用本技能：

• 只提交当前工作，不推送。
• 将 staged 和 unstaged 改动整理为一个本地提交。
• 用 Conventional Commit 信息把当前工作保存到本地。
• 提交正文需要按功能区、界面区、测试、文档或校验结果分段说明。

不要使用

以下场景不要使用本技能：

• 提交并推送请求；请使用 git-pushing-fast。
• 需要将工作分支合并到主分支的双分支流程。
• 强制推送、rebase、squash、amend 或改写历史。
• 创建 Pull Request、发布说明、周报或 changelog 生成。
• git reset --hard、git checkout -- <file> 等破坏性命令。

使用说明

按以下流程顺序执行。目标仓库或用户要求的提交范围不明确时，停止并说明阻塞原因，不要猜测执行。

1. 检查仓库状态。

   • 运行 git status --short 和 git branch --show-current。
   • 先看暂存区统计和实际内容：git diff --cached --stat 与 git diff --cached；如果没有暂存改动，再看 git diff --stat 与 git diff。
   • 需要脚本友好地解析状态时，使用 git status --porcelain。
   • 不得丢弃或回滚用户改动。

2. 暂存改动。

   • 用户要求提交全部改动时，执行 git add -A。
   • 用户指定更小范围时，只暂存指定范围。
   • 仅当用户要求的范围需要逻辑分组时，使用指定文件、路径模式或 git add -p。
   • 重新运行 git status --short，确认目标文件已经暂存。
   • 禁止让已知密钥文件留在待提交暂存区，包括 .env、凭证文件、私钥或 token。

3. 生成提交信息。

   • 使用 Conventional Commits：type(scope): 中文摘要。
   • 根据实际 diff 选择 type 和 scope，不得只根据文件名判断。
   • 对非简单改动，提交正文必须包含 2-5 个简短分段。
   • 分段标题命名受影响区域，下面用列表说明具体变化。
   • 如果运行了测试、校验、hook 或手动验证，需要加入“测试：”或“验证：”分段。

分段正文示例：

fix(module): 调整组件行为

行为：
- 调整受影响组件的默认状态。
- 对不支持的输入保持原有行为不变。

实现：
- 将重复逻辑移动到小型辅助函数。
- 更新相关配置以使用新的辅助函数。

测试：
- 补充更新行为的覆盖用例。
- 提交前运行相关校验。

4. 提交。

   • 使用多个 -m 参数或其他无交互方式执行 git commit，确保正文被完整保留。
   • 禁止使用 --no-verify。
   • hook 或校验失败时，先修复失败原因，再重新提交。

5. 汇报。

   • 最终回复保持简洁。
   • 说明提交哈希、分支、已提交文件摘要和已运行的校验。
   • 明确说明没有执行推送。

安全协议

• 禁止推送。
• 禁止修改 global 或 system Git config。
• 除非用户明确要求，禁止运行 git reset --hard 或 git checkout -- <file> 等破坏性命令。
• 禁止跳过 hooks。
• 禁止提交密钥。