用途
git-commit-workflow 是一个 Git 提交工作流技能，用于在用户请求提交、暂存或查看状态时，按结构化流程协助完成 Git 提交。其核心目标是生成格式统一的提交信息，并遵循中文团队的提交约定。
主要能力
- 状态检查：通过
git status --porcelain读取当前仓库状态，并将结果分为已暂存文件与未暂存文件（含新增和修改）呈现给用户。 - 交互式暂存：只要存在未暂存变更，就会请用户选择需要暂存的文件，再执行
git add <path1> <path2> ...。 - 提交信息生成：通过
git diff --staged获取暂存区差异，并据此生成提交信息草稿。 - 提交信息格式：
<type>: <简洁描述> ← title（最大 80 字符）
<简要说明变更内容> ← description（必填，1-2 句）
Log: <简洁描述> ← title 去掉 type 前缀
PMS: <BUG-number or TASK-number> ← 可选
Issue: Fixes #<number> ← 可选
Influence: <影响说明> ← 可选，仅在影响较大时添加
- 类型选项：feat、fix、docs、style、refactor、perf、test、chore、ci。
- PMS/Issue 条件判断：按顺序判断，若项目名以 dde- 或 deepin- 开头（通过
basename $(git rev-parse --show-toplevel)获取），或用户明确提到 PMS/Issue，则为必填；否则为可选，不主动询问。 - PMS 编号解析：支持 PMS URL（如
https://pms.uniontech.com/task-view-385999.html解析为 TASK-385999，https://pms.uniontech.com/bug-view-123456.html解析为 BUG-123456）以及直接格式 BUG-123456 或 TASK-123456。 - GitHub Issue 解析：支持 Issue URL、
#183或owner/repo#183格式；通过git remote get-url origin判断是否属于当前仓库，属于当前仓库用#<number>，否则用owner/repo#<number>。 - 提交前确认：以草稿框形式展示完整提交信息，并询问 Confirm? (Yes/No/Modify)。仅在用户确认后执行
git commit -m "<commit message>"。
使用方式
当用户请求提交、暂存或查看状态时触发。流程依次为：检查状态、按需暂存文件、获取暂存差异并生成草稿、解析 PMS/Issue、用户确认、执行提交。技能强调绝不自动提交，必须获得用户明确批准。
适用场景
适用于需要统一提交信息规范的中文团队开发流程，尤其是对提交信息结构、PMS/Issue 关联有要求的项目。
限制与特殊处理
- 标题不得超过 80 字符；description 为必填。
- Log 行由标题去掉 type 前缀自动生成；Influence 仅在影响较大时添加。
- 初始提交时若仓库尚无提交，
git commit -m可自动作为首个提交工作。 - 若
git diff --staged无输出，则提示用户没有暂存变更，需先暂存文件。 - 若用户明确表示没有 PMS 或 Issue 编号，则省略对应行。