用途：在提交代码时使用，让每次提交都是原子化、描述清晰且可回退的，保证仓库在任一点检出都能正常工作。
主要能力：规定提交信息结构，格式为 type: Short description（最长72字符），可附带正文说明“改了什么与为什么”以及页脚（问题引用、破坏性变更），例如 Refs: #123。类型包括 feat、fix、docs、style、refactor、test、chore。强调一次提交只做一个逻辑变更，能通过全部测试、可干净回退；若含多个变更应拆分，用 git add 指定文件分别提交。
使用方式：提交前先运行测试与检查，如 pnpm test、pnpm build、pnpm typecheck、pnpm lint，任一失败先修复。流程为：用 git diff 查看改动，git add 或 git add -p 选择性暂存，用 git diff --staged 复查，再写信息提交；复杂改动用 git commit 打开编辑器写完整信息。提交后用 git show --stat 检查，并可再跑 pnpm test 验证。未推送时可修正笔误或补充漏暂存文件，用 git commit --amend；已推送或他人已基于其工作则不应 amend，应使用 git revert 生成反向提交，不要改写共享分支历史或强制推送。
适用场景：与 issue-driven-development 和 pr-creation 流程配合，在开发过程中及创建 PR 前强制执行。
限制：资料未提供具体语言、平台或工具版本要求；示例中的包管理器命令为 pnpm，其他环境需按实际替换。资料未说明收费、价格、效果或安装方式，暂未提供。