SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsgit-pushing-fast-cn

git-pushing-fast-cn

Coding & development

View repository

Updated 10-16 04:42

About this skill

Git Quick Commit and Push

Overview

Quickly and safely commit and push local changes on the current branch of the current repository.

The default result is a focused Conventional Commit, then push to the remote tracked by the current branch. It is necessary to analyze the actual diff, stage the change scope requested by the user, and generate the commit message based on the change content; for non-trivial changes, a sectioned commit body is needed so reviewers can quickly understand the change content by topic.

This flow applies to ordinary single-branch delivery, for example saving the current work to the remote; it does not handle branch merging, history rewriting, or PR creation.

Conventional Commit Rules

Basic format:

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

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

[footer: mandatory for breaking changes; related issue references can be filled in as needed]


在本技能中，正文只对简单提交可选。非简单改动必须写分段正文；如果运行了测试、校验、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
- 提交正文需要按功能区、界面区、测试、文档或校验结果分段说明

## 不要使用

以下场景不要使用本技能：
- 需要将工作分支合并到主分支的双分支流程
- 强制推送、rebase、squash、amend 或改写历史
- 创建 Pull Request，除非用户在推送后明确要求
- 代码评审、发布说明、周报或 changelog 生成
- `git reset --hard`、`git checkout -- <file>` 等破坏性命令

## 使用说明

按以下流程顺序执行。目标仓库、分支或推送目的地不明确时，停止并说明阻塞原因，不要猜测执行。

1. 检查仓库状态。
   - 运行 `git status --short`、`git branch --show-current` 和 `git remote -v`。
   - 可用时通过 `git rev-parse --abbrev-ref --symbolic-full-name @{u}` 检查 upstream。
   - 先看暂存区统计和实际内容：`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 或手动验证，需要加入“测试：”或“验证：”分段。

分段正文示例：

```text
fix(module): 调整组件行为

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

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

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

  1. Commit.

    • Use multiple -m parameters or another non-interactive method to execute git commit, ensuring the body is fully preserved.
    • Do not use --no-verify。
    • If a hook or validation fails, first fix the cause of the failure, then commit again.

  2. Push.

    • When the current branch already has an upstream, execute git push。
    • When the current branch has no upstream, execute git push -u origin <current_branch>, unless the repository or the user specifies another remote.
    • If the push is rejected due to remote updates, first git fetch and check the differences before deciding the next step.
    • Do not force-push unless the user explicitly requests it and confirms the risk.
    • Do not force-push to main or master .

  3. Report.

    • Keep the final reply concise.
    • State the commit hash, branch, remote push result, and validations that were run.
    • If the host application supports Git directives, emit the relevant directives only after the corresponding Git action succeeds.

Safety Protocol

  • Do not modify the global or system Git config.
  • Unless the user explicitly requests it, do not run git reset --hard or git checkout -- <file> and other destructive commands.
  • Do not skip hooks.
  • Do not commit secrets.