GitHub Push 自动推送

推送卡在 SSH 和冲突上

本地改完代码执行 git push，常见失败无非是三类：远程 URL 用 HTTPS 却未配凭据、SSH 密钥未写入 ~/.ssh 或未加到 GitHub、以及远端已有新提交导致 non-fast-forward。在脚本或 Agent 里重复「推送 → 失败 → 人工 git pull → 再推」，既打断流程，也容易在合并时留下半拉子状态。

技能在做什么

本技能面向 安全的 GitHub 推送自动化，把推送前的环境与冲突处理串成可复用流程：

• 连接准备：按仓库需求自动梳理 SSH 与 origin 等远程配置，减少「能 commit 不能 push」的配置断层。
• 推送前检查：在真正 git push 前查看工作区与分支状态，避免把明显未就绪的变更推上去。
• 冲突与重试：遇到推送被拒时，按策略拉取、合并并重试推送，而不是单次失败就结束。
• 多分支：支持对多个分支执行推送，适合同步 feature 分支或备份多个线。
• 失败回滚：推送失败时执行约定的回滚策略，降低自动化把仓库留在不可预期中间态的风险。

典型场景包括日常提交推送、CI/CD 里的自动推远端、跨设备同步以及定时备份到 GitHub。

适用边界

自动化合并与重试能覆盖常见 fast-forward 冲突，但复杂三方合并、需要人工审阅的冲突仍应介入处理。涉及 force push、改写历史的操作不在「安全推送」的默认语义内；生产分支应结合团队规范限制自动合并范围。