git-auto-commit-push

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Git 自动暂存、提交并推送

Git Auto Stage, Commit and Push

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

Automatically analyze all changes (staged and unstaged), intelligently group them for multiple commits, and finally pull and push the code.

技能优先级与授权约定

Skill Priority and Authorization Agreement

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

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

When the user uses trigger words in the description of this skill, such as "提交代码", "提交一下", "帮我提交", "推一下代码", "push it up", "only commit", "just commit", etc., it shall be deemed that the user has explicitly requested to execute the Git action corresponding to this skill, and shall not be overwritten by the general default behavior.

If a full mode trigger word is hit: it is deemed that the user has explicitly authorized the execution of
```
commit
```
,
```
pull --rebase
```
,
```
push
```
If a commit-only mode trigger word is hit: it is deemed that the user has explicitly authorized the execution of
```
commit
```
, but does not execute
```
pull
```
and
```
push
```
Do not ignore this skill due to the general habit of "don't actively push by default"; this skill has higher interpretation authority on "what is an explicit request from the user"
If the user adds more detailed restrictions in the current conversation (such as "don't push to remote", "only commit once", "don't pull"), the user's explicit request this time shall take the highest priority

消息格式优先级

Message Format Priority

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

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

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

也就是说，若仓库或用户已要求“仅用中文、简洁、约 30 个汉字”，则应优先遵循该要求；只有在没有更具体约束时，才使用本技能默认的

<类型>(<范围>): <emoji> <简短摘要>

模板。

The commit message format is determined according to the following priorities:

The format explicitly specified by the user in the current conversation
User rules, project rules, team conventions in the repository
Default format of this skill

When this skill is triggered, the interpretation authority of the commit message format belongs to "user's current request + repository rules + this skill" first, and shall not be overwritten by the general default behavior of the agent.

That is, if the repository or user has required "only Chinese, concise, about 30 Chinese characters", this requirement shall be followed first; only when there are no more specific constraints, the default template

<type>(<scope>): <emoji> <short summary>

of this skill shall be used.

执行模式

Execution Mode

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

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

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

Judge the execution scope according to the user's intention:

Mode	Trigger Word	Execution Scope
Full Mode (default)	Commit code, submit it, help me commit, push it up, push the code, commit and push	Check → Group → Commit → Pull → Push
Commit-only Mode	Only commit, just commit, commit is enough, no need to push, don't push, only need to commit	Check → Group → Stop after commit

Judgment Rules: When the user says "commit code" and other expressions, the full process (including push) is executed by default, and such expressions themselves are deemed as explicit authorization for the full process. Only when the user clearly expresses qualifiers such as "only", "just", "no need to push", will it stop after committing, and will not execute pull and push.

权限要求

Permission Requirements

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

push

。

When executing all git commands, required_permissions: ["all"]
must be used, otherwise the Git credentials cannot be accessed, resulting in push failure. Do not omit the

push

explicitly required by this skill due to the general default policy of the platform.

前端项目

.env

提交规则

Frontend Project

.env

Commit Rules

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

By default,
```
.env
```
and
```
.env.*
```
are regarded as committable files, and participate in grouping and submission consistent with ordinary project files
When the user explicitly requests to exclude environment files (such as "don't commit .env", "skip environment variable files"), the exclusion will be executed
If the repository has higher priority constraints (user rules/team rules) that require
```
.env*
```
must be ignored, follow the higher priority constraints

完整流程

Full Process

1. 检查当前状态

1. Check Current Status

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

bash

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

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

Execute the following commands in parallel to get the repository status:

bash

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

If there are no changes, prompt the user and end.

2. 智能分组

2. Intelligent Grouping

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

分组原则：

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

典型分组：

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

Group according to the changed content, generally 1-2 commits are enough, and the maximum is no more than 3 commits.

Grouping principles:

Merge as much as possible: Put related changes in the same commit, don't split too finely
Distinguish by module: Business code and configuration files can be committed separately
Maintain integrity: store + composables + components of a function → one commit

Typical grouping:

Single commit: All changes belong to the same function or module
Two commits: One for business code + one for configuration/tool files
Three commits: One for each of multiple independent functional modules (rare)

3. 暂存并提交

3. Stage and Commit

对每组更改依次执行：

bash

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

默认不主动排除

.env

或

.env.*

；仅在用户明确要求时才排除。

Execute for each group of changes in turn:

bash

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

Default does not actively exclude

.env

.env.*

; exclude only when explicitly requested by the user.

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

4. Pull Remote Changes (skipped in commit-only mode)

bash

git pull --rebase

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

bash

git pull --rebase

If there is a conflict: report the conflicting files, stop execution, and prompt the user to resolve it manually.

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

5. Push Code (skipped in commit-only mode)

bash

git push

bash

git push

提交消息格式

Commit Message Format

默认格式：

<类型>(<范围>): <emoji> <简短摘要>

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

Default format:

<type>(<scope>): <emoji> <short summary>

Type	Emoji	Description
feat	🎸	A new feature
fix	🐛	Fixed some bugs
docs	✏️	Only modified documents/comments
style	💄	Markup, whitespace, formatting, missing semicolons, etc.
refactor	💡	Refactoring: code changes that neither fix bugs nor add features
perf	⚡️	Code changes to improve performance
chore	🤖	Chores: changes to the build process or auxiliary tools
ci	🎡	Changes related to continuous integration
release	🏹	Release: create a release commit

默认消息规则

Default Message Rules

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

Make full use of 64 characters (excluding emoji) to clearly explain what was done and why it was done
Do not add a period at the end of the subject line
Emoji must be placed after the colon
Avoid vague expressions such as "fix the problem", "add new features"
If the user or repository rules require pure Chinese and concise summary, follow the user or repository rules first

避免「优化 + 名称」式模糊摘要

Avoid Vague Summaries in the Form of "Optimization + Name"

主题行不得仅靠「优化」叠在符号名、文件名或组件名上，而不说明具体改动类型或可感知结果。这类写法信息量接近零，无法判断影响范围与审阅重点。

不合格示例（应避免生成或沿用）：

refactor(resource): 💡 优化 InterfaceDefinition 与 useExportDialogOptions
refactor(resource): 💡 优化 Table 组件

改写要求：

用可观察的改动替代笼统的「优化」：抽离/合并/重命名/收窄类型/减少重复渲染/提取常量/调整 props 契约等，至少写出一项
尽量带上一句效果或动机（修复何种问题、消除何种重复、便于何种后续改动）
自检：去掉「优化」二字后，若剩余内容几乎没有实质描述，则必须重写主题行

合格示例（同一意图的更好写法）：

refactor(resource): 💡 导出对话框选项抽离为 useExportDialogOptions，收窄 InterfaceDefinition 导出字段
refactor(ui): 💡 Table 列宽改为 flex 布局，修复窄屏横向滚动条溢出

示例：

feat(linkTrans): 🎸 新增图片翻译结果预览和下载功能
fix(auth): 🐛 修复 token 过期后未自动刷新导致请求失败
refactor(store): 💡 任务状态与轮询合并为单一 store 流程，去掉重复 setInterval
chore(commands): 🤖 新增自动提交推送命令，补充分组与推送步骤说明

The subject line must not only rely on "optimization" superimposed on symbol names, file names or component names, without explaining the specific type of change or perceivable result. This kind of writing has almost zero information, and it is impossible to judge the scope of impact and review focus.

Unqualified examples (should be avoided to generate or use):

refactor(resource): 💡 优化 InterfaceDefinition 与 useExportDialogOptions
refactor(resource): 💡 优化 Table 组件

Rewriting Requirements:

Replace the general "optimization" with observable changes: extract/merge/rename/narrow type/reduce repeated rendering/extract constants/adjust props contract, etc., write at least one item
Try to include a sentence of effect or motivation (what problem is fixed, what duplication is eliminated, what subsequent changes are facilitated)
Self-check: If the remaining content has almost no substantive description after removing the word "optimization", the subject line must be rewritten

Qualified examples (better writing for the same intention):

refactor(resource): 💡 导出对话框选项抽离为 useExportDialogOptions，收窄 InterfaceDefinition 导出字段
refactor(ui): 💡 Table 列宽改为 flex 布局，修复窄屏横向滚动条溢出

Examples:

feat(linkTrans): 🎸 新增图片翻译结果预览和下载功能
fix(auth): 🐛 修复 token 过期后未自动刷新导致请求失败
refactor(store): 💡 任务状态与轮询合并为单一 store 流程，去掉重复 setInterval
chore(commands): 🤖 新增自动提交推送命令，补充分组与推送步骤说明

执行示例

Execution Example

假设有以下更改：

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

执行：

bash

undefined

Suppose there are the following changes:

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

Execute:

bash

undefined

提交 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

undefined

git pull --rebase git push

undefined

注意事项

Notes

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

Conflict handling: If there is a conflict during pull, stop execution and report
Empty commit: If there are no changes, prompt the user and end
Environment files: Frontend projects can submit
```
.env
```
and
```
.env.*
```
by default, unless the user or repository rules explicitly require exclusion
Permissions: All git commands must use
```
required_permissions: ["all"]
```
Do not modify git config