GitHub 一键发布助手（专业版）

解决什么问题

手工把项目推上 GitHub，流程本身不复杂，但容易在细节上翻车：.env 里的数据库密码被提交、node_modules/ 和 __pycache__/ 混进首次 commit、新仓库缺少 .gitignore 和 LICENSE、git push 卡在认证弹窗、CRLF 警告误以为报错、老仓库还在用 master。这个技能把「开源准备 → 安全检查 → 提交 → 推送」串成一条可复核的流水线，每一步都有明确的输入和输出，减少手工操作带来的遗漏。

核心能力与关键步骤

• 前置检查：先确认当前目录是否已有 git 仓库，再跑 gh auth status 检查 GitHub CLI 是否登录；未登录会提示执行 gh auth login，或走 Windows Credential Manager 的 git push 交互认证。同时向用户确认仓库名、是否私有、是否需要 LICENSE 和初始 tag。
• 安全检查（强制）：先跑 git status 看清将要提交的文件，扫描 .env、*.pem、*.key、id_rsa*、credentials.json、__pycache__/、node_modules/、dist/、build/、.workbuddy/memory/、.idea/、.vscode/ 等敏感或无意义内容，发现即告警并要求用户确认；.gitignore 缺失时按语言模板（Python / Node / Go / Rust）补齐。
• 开源标配补齐：按需生成 .gitignore、LICENSE（MIT 默认，可选 Apache-2.0 / GPL-3.0）、README.md（含安装、使用、配置示例与 badges）、pyproject.toml 或 package.json，已存在的文件不覆盖。
• 提交与推送：完成 Git 初始化和首次 commit；若 gh 已登录，可用 gh repo create 直接建仓并推送，无需打开浏览器。
• 历史清理与公开措辞：如果敏感信息已经进入历史 commit，指引用户先重置相关密码，再用 git filter-repo 重写历史，并提醒所有协作者重新 clone；发布用的 commit message 和 tag 统一使用中性表述，避免暴露敏感信息处理意图。

适用边界与注意点

• 重写历史后旧 commit hash 失效，已推送的仓库需要所有协作者重新 clone，这是一个破坏性操作，不适合有外部贡献者的活跃仓库。
• 已发布到 PyPI / npm 的版本无法从公共索引删除，只能通过新版本替代。
• 如果仓库曾被公开抓取，历史里的敏感信息可能已被缓存，改密码永远是第一步，清理历史只是补充手段。
• CRLF 警告是 Git for Windows 的默认行为，不需要为了消除警告调整 core.autocrlf。
• 含 !、$ 等字符的配置值不要直接拼进命令行字符串，改用 .env 文件或单引号包裹。