Claude How To为 Claude Code 打造安全的/push-all斜杠命令——一站式 Stage、Commit 与 Push 实战指南【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto导读本指南以 Claude How To 仓库中的 push-all 命令定义乌克兰语版见 uk/01-slash-commands/push-all.md为核心完整讲解如何在 Claude Code 中通过一条/push-all斜杠命令让 AI 在「安全检查 → 人工确认 → 暂存 → 生成 Conventional Commit → 推送 → 验证」的受控流程下完成 Git 提交与推送。读完本文你将掌握该命令的完整工作流、七类风险检测规则、API 密钥校验模式以及如何借助仓库中的 Hooks 示例进一步加固你的提交流水线。一、/push-all是什么/push-all是 Claude How To 仓库01-slash-commands/目录下提供的一个示例斜杠命令其核心职责是将当前工作区所有变更加入暂存区git add .、创建提交git commit并推送到远程git push。它不是一个「无脑执行」的自动化脚本而是一套带有人工确认闸门与安全扫描的受控流程。命令的元信息定义在其 frontmatter 中--- description: Додати всі зміни до індексу, створити коміт та відправити на віддалений сервер (використовуйте з обережністю) allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git push:*), Bash(git diff:*), Bash(git log:*), Bash(git pull:*) ---description说明该命令的作用——暂存全部变更、创建提交并推送远程同时标注「请谨慎使用」use with caution。allowed-tools白名单限定了命令可调用的工具集合只开放git add、git status、git commit、git push、git diff、git log、git pull相关的 Bash 调用避免 AI 在执行过程中越权使用其他危险命令。在 01-slash-commands/README.md 中/push-all被描述为「Stages all changes, creates a commit, and pushes to remote with safety checks」即自带安全校验的一键提交推送命令。它的安全校验点包括密钥文件、API 密钥真实密钥 vs 占位符、大文件超过 10MB 且未使用 Git LFS、构建产物等。注意自定义斜杠命令在最新版本中已并入 Skills 体系.claude/commands/下的 legacy 命令仍然可用但官方推荐使用.claude/skills/name/SKILL.md的形式。两者都会生成/command-name快捷方式详见 Slash Commands 总览。二、完整工作流七步受控流程/push-all的核心是一套七步工作流每一步都有明确的输入输出与终止条件1. 分析变更并行采集命令启动后并行执行三条只读命令建立对工作区现状的完整认知命令作用git status显示已修改、已新增、已删除、未跟踪的文件git diff --stat显示变更统计各文件增减行数git log -1 --oneline查看最近一次提交作为生成提交信息的风格参考这种「并行采集」的设计与同目录下的 commit.md 一脉相承——后者同样在 Context 区块通过动态 Shell 命令注入当前状态## Context - Current git status: !git status - Current git diff: !git diff HEAD - Current branch: !git branch --show-current - Recent commits: !git log --oneline -10这里的!command语法是 Claude Code 命令/Skills 的动态上下文注入机制在执行提示词之前先运行 Bash 命令把输出拼进发给模型的上下文里让 AI 不必「猜测」仓库当前状态。前缀则用于引用文件内容例如package.json。2. 安全检查强制闸门这是整个命令的灵魂所在。一旦检测到以下五类风险命令必须立即停止并向用户发出警告❌ 必须 STOP 并 WARN 的检测项类别检测目标密钥文件.env*、*.key、*.pem、credentials.json、secrets.yaml、id_rsa、*.p12、*.pfx、*.cerAPI 密钥任何*_API_KEY、*_SECRET、*_TOKEN变量带有真实值而非your-api-key、xxx、placeholder之类的占位符大文件超过 10MB 且未使用 Git LFS 跟踪构建产物node_modules/、dist/、build/、__pycache__/、*.pyc、.venv/临时文件.DS_Store、thumbs.db、*.swp、*.tmpAPI 密钥验证的具体判定模式OPENAI_API_KEYsk-proj-xxxxx # ❌ 检测到真实密钥 AWS_SECRET_KEYAKIA... # ❌ 检测到真实密钥 STRIPE_API_KEYsk_live_... # ❌ 检测到真实密钥 # ✅ 可接受的占位符 API_KEYyour-api-key-here SECRET_KEYplaceholder TOKENxxx API_KEYyour-key SECRET${YOUR_SECRET}✅ 必须验证通过的项目.gitignore配置正确能将密钥、产物、临时文件排除在版本控制之外不存在合并冲突merge conflicts当前分支正确若为main/master需主动警告API 密钥仅以占位符形式存在3. 请求确认人工闸门安全检查通过后命令以结构化摘要的形式向用户呈现变更全貌并等待显式的yes Резюме змін变更摘要: - X файлів змінено, Y додано, Z видаленоX 个文件修改Y 个新增Z 个删除 - Загалом: AAA вставок, -BBB видалень共 AAA 插入、-BBB 删除 Безпека: ✅ Без секретів | ✅ Без великих файлів | ⚠️ [попередження] Гілка: [назва] → origin/[назва] Я виконаю: git add . → commit → push Введіть yes для продовження або no для скасування.硬性规则必须等待用户输入明确的yes之后才能继续。这一设计把「推送远程」这个不可逆操作的控制权始终保留在用户手中是 AI 执行副作用操作时应当遵循的黄金准则。4. 执行暂存确认之后用户确认后按顺序执行git add . git status # 再次核对暂存区内容先git add .将全部变更加入暂存区再立即git status复核索引index状态形成「执行 校验」的闭环。5. 生成提交信息Conventional Commits命令要求 AI 分析变更内容按Conventional Commits 规范生成提交信息格式[тип 类型]: Короткий опис 简短描述不超过 72 个字符 - Ключова зміна 1关键变更 1 - Ключова зміна 2关键变更 2 - Ключова зміна 3关键变更 3允许的类型feat、fix、docs、style、refactor、test、chore、perf、build、ci示例docs: Update concept README files with comprehensive documentation - Add architecture diagrams and tables - Include practical examples - Expand best practices sections这条规则与 pr.md 中 PR 准备清单的第 5 步完全一致也与仓库根目录 CONTRIBUTING.md 的提交规范相呼应保证整个仓库的提交历史风格统一、可机器解析。6. 提交与推送git commit -m $(cat EOF [Згенероване повідомлення коміту 生成的提交信息] EOF ) git push # 若失败: git pull --rebase git push git log -1 --oneline --decorate # 验证这里使用了 heredoccat EOF方式传递多行提交信息避免多行消息在 shell 引号中转义出错。推送失败时自动回退到git pull --rebase git push策略。提交完成后用git log -1 --oneline --decorate验证提交是否成功、分支与标签装饰是否正确。7. 确认成功最终向用户输出结果确认✅ Успішно відправлено на віддалений сервер!已成功推送到远程 Коміт: [хеш 哈希] [повідомлення 消息] Гілка: [гілка 分支] → origin/[гілка 分支] Змінено файлів: X (вставок, -видалень)修改文件数X插入/-删除三、错误处理三类失败的应对策略命令对 Git 操作最常见的三类失败给出了明确的处置路径失败点处理方式git add失败检查文件权限、是否有文件被锁定locked files、确认仓库已正确初始化git initgit commit失败修复 pre-commit 钩子问题检查git config中的user.name/user.email是否配置git push失败① Non-fast-forward执行git pull --rebase git push② 远程无对应分支执行git push -u origin [branch]③ 目标分支受保护改用 PR 流程而非直接推送其中「pre-commit 钩子导致 commit 失败」这一点在本仓库的 06-hooks/pre-commit.sh 中有非常直观的印证。该脚本作为 PreToolUse 钩子matcher 为Bash在检测到 git commit 操作时会按项目类型依次运行测试# 检查 package.jsonNode.js 项目 if [ -f package.json ] grep -q \test\: package.json; then npm test if [ $? -ne 0 ]; then echo ❌ Tests failed! Commit blocked. 2 exit 2 # exit code 2 会阻止工具调用并把 stderr 作为拦截原因 fi fi脚本依次识别package.jsonNode.jsnpm test、pytest.ini/setup.pyPythonpytest、go.modGogo test ./...、Cargo.tomlRustcargo test。Exit code 2 会真正阻断提交其他非零退出码则只报错不阻断——这正是/push-all文档中「commit 失败先查 pre-commit 钩子」的底层原因。Hooks 的完整配置方式见 06-hooks/README.md其基础结构如下{ hooks: { PreToolUse: [ { matcher: Bash, hooks: [ { type: command, command: $CLAUDE_PROJECT_DIR/.claude/hooks/pre-commit.sh, timeout: 60 } ] } ] } }四、何时使用/push-all适用场景与明确禁区✅ 适合使用的场景多文件文档更新一次修改横跨多个文档文件逻辑上属于同一次变更带测试与文档的功能开发功能代码、测试、文档三者天然构成一个完整提交跨文件的 Bug 修复修复点散落在多个文件中且彼此关联全项目格式化/重构formatting或refactoring涉及大量文件无需拆分配置变更如.gitignore、CI 配置、依赖清单的调整❌ 必须避免的场景不确定当前到底会提交哪些内容变更中包含密钥或敏感数据目标分支受保护且未经评审存在合并冲突尚未解决需要粒度化的提交历史例如希望按功能拆分成多个 commitpre-commit 钩子无法通过五、替代方案需要更多控制权时怎么办如果用户希望对提交内容拥有更精细的控制/push-all文档明确建议以下三种替代路径选择性暂存Selective staging人工审查后只git add指定文件避免误提交无关变更交互式暂存Interactive staging使用git add -p以 patch 粒度挑选变更块适合「同一文件包含多个逻辑变更」的场景PR 流程Pull Request workflow创建分支 → 推送 → 发起 Pull Request配合评审流程后再合入主干。仓库提供了专门的/pr命令见 pr.md其检查清单包括prettier --write .、npm test、git diff HEAD审查、Conventional Commit 生成与 PR 摘要撰写。始终牢记推送前务必重新审查变更。心存疑虑时使用独立的 Git 命令逐个操作把控制权牢牢握在自己手里。六、安装与使用把/push-all带入你的项目根据 01-slash-commands/README.md 的安装章节有两种安装方式方式一作为 Skill 安装推荐mkdir -p .claude/skills mkdir -p .claude/skills/push-all cp 01-slash-commands/push-all.md .claude/skills/push-all/SKILL.md方式二作为 Legacy 命令安装# 项目级团队共享会提交进仓库 mkdir -p .claude/commands cp 01-slash-commands/push-all.md .claude/commands/ # 个人级 mkdir -p ~/.claude/commands cp 01-slash-commands/push-all.md ~/.claude/commands/安装完成后在 Claude Code 交互会话中直接输入/push-all命令便会按第二节的七步流程执行分析变更 → 安全检查 → 呈现摘要等待yes→git add .→ 生成 Conventional Commit →git push→ 输出成功确认。七、纵深加固把安全校验沉淀为 Hooks/push-all文档中的安全检测项只是命令执行时的「一次体检」。若要建立持续性的防线可以把同类规则固化到 Claude Code 的 Hooks 体系中让每一次文件写入都被自动扫描。本仓库的 06-hooks/security-scan.sh 就是一个可直接参考的 PostToolUse 钩子它会在Write事件后扫描被写入的文件硬编码密码同时匹配 JSON 格式password: value与代码格式password value硬编码 API 密钥匹配api_key、apikey、access_token等键名带真实值硬编码密钥/令牌、BEGIN ... PRIVATE KEY私钥块AWS 访问密钥匹配AKIA后跟 16 位大写字母数字的模式可选集成semgrep与trufflehog存在时自动调用扫描发现问题时钩子以hookSpecificOutput.additionalContext输出非阻断警告提示开发者改用环境变量。这恰好补足了/push-all检查的短板它拦截的是「推送前」的存量风险而 Hooks 防护的是「写入时」的增量风险两者结合可以形成端到端的密钥防泄漏链路。八、小结/push-all的价值不在于「一键提交」本身而在于它展示了一条AI 执行高风险 Git 操作的正确范式只读先行先并行采集status/diff --stat/log让决策建立在事实之上安全闸门五类风险检测 API 密钥真实值识别 .gitignore/合并冲突/分支校验人工确认结构化摘要 显式yes才放行绝不自作主张规范提交自动生成 Conventional Commit保持提交历史整洁可读失败预案对 add / commit / push 三类失败给出明确处置路径并能在需要时优雅降级为git add -p、选择性暂存或 PR 流程。结合仓库中的 commit.md、pr.md 以及 06-hooks 下的钩子脚本你可以搭建起一套从「开发 → 提交 → 评审 → 推送」全链路受控、防泄漏的 Git 工作流。本文基于 Claude How To 仓库文档编写。相关文件push-all.md英文原版、push-all.md乌克兰语版、Slash Commands 总览。【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考