Git 自动暂存、提交并推送

自动分析所有更改（已暂存和未暂存），智能分组进行多次提交，最后拉取并推送代码。

技能优先级与授权约定

当用户使用本技能描述中的触发词，如“提交代码”“提交一下”“帮我提交”“推一下代码”“push 上去”“仅提交”“只 commit”等，应视为用户已明确要求执行本技能对应的 Git 动作，不要再被通用默认行为覆盖。

• 命中完整模式触发词：视为用户已明确授权执行 commit、pull --rebase、push
• 命中仅提交模式触发词：视为用户已明确授权执行 commit，但不执行 pull 和 push
• 不要因为通用的“默认不要主动 push”习惯而忽略本技能；本技能对“什么叫用户已明确要求”有更高解释权
• 如果用户在当前对话中又追加了更细的限制（如“别推远程”“只提交一条”“不要拉取”），以用户当次明确要求为最高优先级

消息格式优先级

提交消息格式按以下优先级决定：

1. 用户在当前对话中明确指定的格式
2. 仓库中的用户规则、项目规则、团队约定
3. 本技能默认格式

当本技能被触发时，提交消息格式的解释权优先属于“用户当前要求 + 仓库规则 + 本技能”，不要被代理的通用默认行为覆盖。

也就是说，若仓库或用户已要求“仅用中文、简洁、约 30 个汉字”，则应优先遵循该要求；只有在没有更具体约束时，才使用本技能默认的 <类型>(<范围>): <emoji> <简短摘要> 模板。

执行模式

根据用户意图判断执行范围：

模式	触发词	执行范围
完整模式（默认）	提交代码、提交一下、帮我提交、push 上去、推一下代码、commit and push	检查 → 分组 → 提交 → 拉取 → 推送
仅提交模式	仅提交、只 commit、commit 就行、不用推、不用 push、只需要提交	检查 → 分组 → 提交即停止

判断规则：用户说"提交代码"等表述时，默认执行完整流程（含推送），这类表述本身就视为对完整流程的明确授权。只有用户明确表达"仅"、"只"、"不用推"等限定词时，才在提交后停止，不执行拉取和推送。

权限要求

执行所有 git 命令时，必须使用 required_permissions: ["all"]，否则无法访问 Git 凭据导致推送失败。不要因为平台通用默认策略而省略本技能已明确要求执行的 push。

前端项目 .env 提交规则

• 默认将 .env、.env.* 视为可提交文件，与普通项目文件一致参与分组与提交
• 当用户明确要求排除环境文件（如“不要提交 .env”“跳过环境变量文件”）时，才执行排除
• 若仓库已有更高优先级约束（用户规则/团队规则）要求必须忽略 .env*，则遵循更高优先级约束

完整流程

1. 检查当前状态

并行执行以下命令获取仓库状态：

git status --porcelain
git diff --cached --name-status
git diff --name-status
git log --oneline -5

如果没有任何更改，提示用户并结束。

2. 智能分组

根据更改内容进行分组，一般 1-2 次提交即可，最多不超过 3 次。

分组原则：

• 尽量合并：相关更改放在同一个提交中，不要拆得太细
• 按模块区分：业务代码和配置文件可以分开提交
• 保持完整性：一个功能的 store + composables + 组件 → 一个提交

典型分组：

• 单次提交：所有更改属于同一功能或模块
• 两次提交：业务代码一次 + 配置/工具文件一次
• 三次提交：多个独立功能模块各一次（较少见）

3. 暂存并提交

对每组更改依次执行：

git add <file1> <file2> ...
git commit -m "<类型>(<范围>): <emoji> <简短摘要>"

默认不主动排除 .env 或 .env.*；仅在用户明确要求时才排除。

4. 拉取远程更改（仅提交模式跳过）

git pull --rebase

如果有冲突：报告冲突文件，停止执行，提示用户手动解决。

5. 推送代码（仅提交模式跳过）

git push

提交消息格式

默认格式： <类型>(<范围>): <emoji> <简短摘要>

类型	Emoji	说明
feat	🎸	一个新的功能
fix	🐛	修补了一些 bug
docs	✏️	只修改了文档/注释
style	💄	标记、空白、格式化、丢失的分号等等
refactor	💡	重构：既不修复 bug 也不添加特性的代码更改
perf	⚡️	提高性能的代码更改
chore	🤖	杂务：构建过程或辅助工具变更
ci	🎡	持续集成相关修改
release	🏹	发布：创建一个发布的提交

默认消息规则

• 充分利用 64 个字符（不含 emoji），清晰说明做了什么、为什么做
• 不要在主题行末尾加句号
• Emoji 必须放在冒号后面
• 避免"修复问题"、"新增功能"这类模糊表述
• 若用户或仓库规则要求纯中文、简洁摘要，则优先遵循用户或仓库规则

示例：

feat(linkTrans): 🎸 新增图片翻译结果预览和下载功能
fix(auth): 🐛 修复 token 过期后未自动刷新导致请求失败
refactor(store): 💡 重构任务状态管理，优化轮询逻辑
chore(commands): 🤖 新增自动提交推送命令，优化开发流程

执行示例

假设有以下更改：

M  src/modules/agent/linkTrans/index.vue
M  src/modules/agent/linkTrans/stores/useLinkTransStore.ts
A  src/modules/agent/linkTrans/components/NewFeature.vue
M  .cursor/commands/git-commit.md
M  tailwind.config.js

执行：

# 提交 1: linkTrans 模块
git add src/modules/agent/linkTrans/index.vue src/modules/agent/linkTrans/stores/useLinkTransStore.ts src/modules/agent/linkTrans/components/NewFeature.vue
git commit -m "feat(linkTrans): 🎸 新增翻译结果组件，优化 store 状态管理逻辑"

# 提交 2: 配置文件
git add .cursor/commands/git-commit.md tailwind.config.js
git commit -m "chore(config): 🤖 更新 git 提交命令和 tailwind 主题配置"

# 拉取并推送
git pull --rebase
git push

注意事项

• 冲突处理：pull 时有冲突则停止执行并报告
• 空提交：没有任何更改则提示用户并结束
• 环境文件：前端项目默认可提交 .env、.env.*，除非用户或仓库规则明确要求排除
• 权限：所有 git 命令必须使用 required_permissions: ["all"]
• 不要修改 git config