Back to Details

git-commit-push

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Purpose

目的

Safely create a git commit and push it to GitHub with explicit scope, clear commit message quality, and user confirmation gates.
安全地创建git commit并将其推送到GitHub，确保提交范围明确、提交消息质量清晰，并设置用户确认环节。

Scope

适用范围

  • In scope: inspect working tree, stage intended files, create commit, push to remote branch, report result.
  • Out of scope: destructive history rewriting by default, force-push by default, rewriting unrelated user changes.
  • 包含内容：检查工作区、暂存目标文件、创建commit、推送到远程分支、报告结果。
  • 排除内容：默认不执行破坏性历史重写操作、默认不强制推送、不修改无关的用户更改。

Required Inputs

必填输入

  • Target repository path
  • Branch strategy:
    • Use current branch, or
    • Create/switch to a new branch name
  • Commit scope:
    • Included files/patterns
    • Excluded files/patterns
  • Commit message intent (summary and rationale)
  • Push target (remote + branch) if different from default
If commit scope is not explicit, infer from recent task context and present the exact file list before committing.
  • 目标仓库路径
  • 分支策略：
    • 使用当前分支，或
    • 创建/切换到新分支名称
  • 提交范围：
    • 包含的文件/模式
    • 排除的文件/模式
  • 提交消息意图（摘要和理由）
  • 推送目标（远程仓库+分支）（若与默认不同）
如果提交范围不明确，则从最近的任务上下文推断，并在提交前展示确切的文件列表。

Safety Rules

安全规则

  • Never run destructive commands such as hard reset or checkout discard unless explicitly requested.
  • Never include unrelated file changes without user approval.
  • Never force-push unless user explicitly asks.
  • Never amend commits unless explicitly asked.
  • Prefer non-interactive git commands.
  • 除非明确请求，否则绝不执行诸如硬重置（hard reset）或丢弃检出（checkout discard）等破坏性命令。
  • 未经用户批准，绝不包含无关的文件更改。
  • 除非用户明确要求，否则绝不强制推送（force-push）。
  • 除非明确要求，否则绝不修改提交（amend commits）。
  • 优先使用非交互式git命令。

Workflow

工作流程

  1. Repository and branch check
  • Verify current repository and branch.
  • Verify remote availability.
  1. Change inventory
  • Show staged and unstaged files.
  • Summarize change intent by file.
  1. Scope confirmation gate
  • Propose exact files to stage.
  • Ask for confirmation when ambiguity exists.
  1. Stage and validate
  • Stage only approved files.
  • Re-check staged diff summary.
  1. Commit creation
  • Generate concise commit message using this structure:
    • Subject: imperative, <= 72 chars
    • Body: what changed and why (when needed)
  • Create commit.
  1. Push
  • Push to selected remote/branch.
  • If branch has no upstream, set upstream on first push.
  1. Result report
  • Return commit hash, branch, remote, push status, and any follow-up suggestions.
  1. 仓库和分支检查
  • 验证当前仓库和分支。
  • 验证远程仓库是否可用。
  1. 变更清单
  • 展示已暂存和未暂存的文件。
  • 按文件总结变更意图。
  1. 范围确认环节
  • 提议确切的暂存文件。
  • 存在歧义时请求确认。
  1. 暂存与验证
  • 仅暂存已批准的文件。
  • 重新检查已暂存的差异摘要。
  1. 创建提交
  • 使用以下结构生成简洁的提交消息：
    • 主题：祈使语气，≤72字符
    • 正文：说明变更内容及原因（必要时）
  • 创建commit。
  1. 推送
  • 推送到选定的远程仓库/分支。
  • 如果分支没有上游分支，首次推送时设置上游。
  1. 结果报告
  • 返回提交哈希（commit hash）、分支、远程仓库、推送状态以及任何后续建议。

Commit Message Policy

提交消息规范

Use conventional-style prefixes when appropriate:
  • feat: new feature
  • fix: bug fix
  • refactor: internal restructuring
  • docs: documentation-only changes
  • test: tests added or changed
  • chore: maintenance or tooling changes
Example:
  • feat(auth): add DCF token refresh validation
适当时使用常规风格的前缀：
  • feat: 新功能
  • fix: 修复bug
  • refactor: 内部重构
  • docs: 仅文档变更
  • test: 添加或修改测试
  • chore: 维护或工具变更
示例：
  • feat(auth): add DCF token refresh validation

Required Output

必填输出

Provide all items:
  1. Files committed
  2. Commit message used
  3. Commit hash
  4. Branch and remote pushed to
  5. Push status
  6. Any skipped files and why
提供以下所有内容：
  1. 已提交的文件
  2. 使用的提交消息
  3. 提交哈希
  4. 推送至的分支和远程仓库
  5. 推送状态
  6. 任何跳过的文件及原因

Failure Handling

故障处理

  • If push fails due to auth: report exact git error and suggest credential check.
  • If push fails due to non-fast-forward: stop, summarize divergence, propose pull/rebase strategy.
  • If branch protection blocks push: report protection rule and suggest PR workflow.
  • 如果因认证失败导致推送失败：报告确切的git错误并建议检查凭据。
  • 如果因非快进（non-fast-forward）导致推送失败：停止操作，总结分歧情况，提议拉取/变基策略。
  • 如果分支保护规则阻止推送：报告保护规则并建议PR工作流程。

Optional PR Handoff

可选PR交接

If requested, prepare PR-ready summary:
  • Title suggestion
  • Summary bullets
  • Test evidence bullets
  • Risk/rollback notes
如果用户要求，准备可用于PR的摘要：
  • 标题建议
  • 摘要要点
  • 测试证据要点
  • 风险/回滚说明

Hard Gates

强制限制

  • Do not commit without explicit scope.
  • Do not push if commit failed.
  • Do not force-push or amend without explicit user instruction.
  • Stop if unexpected unrelated changes appear and ask user how to proceed.
  • 没有明确范围时不得提交。
  • 提交失败时不得推送。
  • 未经用户明确指示，不得强制推送或修改提交。
  • 若出现意外的无关变更，停止操作并询问用户如何处理。