推送到远程

把已经完成的本地提交推到远程，并在推之前把"推错地方、推错内容、覆盖别人"这三类不可逆后果挡住。推送会改变远程状态且不易悄悄撤回，因此先核对、再确认、后执行、最后验证。

先确定任务边界

• 用户明确要求推送时才执行 git push。用户只说"提交"时，完成提交即可，不顺手推送。
• 只在当前分支推送到它已有的 upstream。不新建分支、不改 remote 配置、不改写历史，除非用户明确要求。
• --force / --force-with-lease / 删除远程分支 / 推送 tags 都属于高风险动作，必须单独向用户确认，不能从"帮我推一下"里推断授权。
• 推送目标仓库可能是团队共享仓库。即使有权限，也要先把"将要上传哪些提交"讲清楚再推。

持久推送授权

逐次确认常规推送会拖慢节奏，因此本仓库支持把授权固化为配置，而不是每轮重问一遍：

• 读本机被 gitignore 的 local-config.json（仓库内提交的 local-config.template.json 给出字段说明）。
• pushAuthorized: true —— 常规推送无需逐次确认，直接执行并在报告中说明依据。
• forcePushAuthorized: true —— 仅这一项才放行 --force-with-lease。它与 pushAuthorized 互不蕴含：拿到"直接推送"的授权不等于拿到强推授权，也不等于可以推送 tags 或删除远程分支。
• protectedBranches —— 所列分支上即使有强推授权也不允许强推。
• 没有配置文件、配置里没有该项、或授权已过合理期限时，回到逐次确认。

授权放宽的是"问不问"，不是"查不查"。 有了持久授权，推送前的现场核对（分支、upstream、待推送提交、敏感文件）与推送后的远程 ref 验证一步都不能省——那两步是防事故的，不是防打扰的。

推送路径

1. 读现场。 用 git status -sb 拿到当前分支、upstream 与领先/落后提交数；用 git remote -v 确认远程地址与协议；用 git log --oneline @{upstream}..HEAD 列出这次真正会推上去的提交。如果工作区有未提交改动，说明它们不会被推送，不要替用户顺手提交。
2. 判定推送形态。 按实际情况归入一种，并向用户说明：
   • 快进推送（本地领先、远程未变）：常规情况，风险最低。
   • 远程有新提交（本地落后或分叉）：先停。默认选择 git pull --rebase（或按仓库既有约定 merge）后再推，不要用强推把别人的提交抹掉。
   • 无 upstream 的新分支：需要 -u origin <branch> 建立跟踪，且大概率要推送新分支——属于需确认的动作。
   • 强推场景（消息改写、rebase 后、回滚提交）：只允许 --force-with-lease，并在推送前确认远程 ref 未被他人更新。
3. 过安全闸。 推送前逐项核对，任何一项不确定就停下问用户：
   • 目标 remote 与分支是否就是用户要推的那个（尤其存在多个 remote 或 fork 时）。
   • 将要上传的提交里有没有疑似密钥、令牌、.env、local-config.json 等敏感文件。仓库若有 audit-remote-secret-leaks 之类的审计流程，提醒用户先跑；本 skill 不代替泄露审计。
   • 是否有误提交的大文件、构建产物或本地配置。
   • 若推送 tags 或删除分支，单独确认范围。
4. 执行并验证。 推送后不要只看命令退出码：用 git status -sb 确认领先提交归零（或远程 ref 已更新到预期 SHA），用 git log --oneline -1 origin/<branch> 核对远程顶端就是本地顶端。如有 CI 或 hook 输出，说明其状态；触发失败或被拒要如实报告。
5. 失败就给恢复路径。 被 non-fast-forward 拒绝、认证失败、hook 拒绝、protected branch 拦截时，按下文 references 给出具体可执行的恢复步骤，说明每一步会改变什么，并明确哪些需要用户授权。不要用强推"解决"一个本该先合并的冲突。

交付内容

用简洁中文报告：推送目标（remote/分支）→ 本次上传的提交清单 → 执行的命令 → 推送后验证结果 → 未完成或需授权的事项。区分"已推送到远程""仅本地提交""推送被拒未生效"三种状态，不要用含糊表述掩盖没推成功的事实。

与相邻 skill 的边界

• 生成提交信息、创建提交：/commit 命令。
• 推送前的敏感信息泄露审计：audit-remote-secret-leaks。本 skill 只提醒，不做审计结论。
• 发布评审、版本冻结、回滚预案：release-readiness。
• 故障根因定位：systematic-debugging。