Deploy Public

核心用法

deploy-public 是一款专为 GitHub 仓库设计的私有到公有同步工具，采用 bash 脚本实现完整的自动化发布流程。核心执行路径为：克隆公共仓库 → 复制私有仓库内容（自动排除 ai/ 和 .git/ 目录）→ 创建分支并提交 → 发起 Pull Request → 执行常规合并（禁用 squash）→ 同步 GitHub Release 信息。

工具依赖 git、gh（GitHub CLI）和 bash 环境，通过命令行接收两个参数：私有仓库本地路径与目标公共仓库的 GitHub 坐标（org/repo）。典型使用场景为：私有仓库完成版本迭代并生成 Release 后，一键将可公开代码推送至对应公共镜像。

显著优点

• 敏感信息隔离：内置 ai/ 目录过滤机制，适合 AI 开发工作流中保护提示词、模型配置等内部资产
• 流程标准化：强制 PR → 合并 → Release 同步的三段式流程，避免手动操作遗漏
• Release 信息继承：自动拉取私有仓库的 Release Notes，确保公共仓库版本说明完整
• 轻量无依赖：纯 bash 实现，无需额外运行时，兼容主流 CI/CD 环境

潜在局限

• 硬编码依赖：要求私有仓库名必须以 -private 结尾，且公共仓库需预先手动创建
• 权限门槛高：需要 gh CLI 已认证且具有目标仓库的写权限及合并权限
• 无冲突处理：未提及文件冲突时的解决策略，复杂场景可能失败
• 平台锁定：仅支持 GitHub，不兼容 GitLab、Gitee 等平台
• 单点执行风险：自动合并操作不可逆，若私有仓库误含敏感文件将直接公开

适合人群

• 采用 "private development + public release" 模式的开源项目维护者
• 需要隔离 AI 相关资产（提示工程、微调数据）的 ML/AI 工程团队
• 已通过 wip-release 等工具标准化私有仓库 Release 流程的开发者

常规风险

• 信息泄露：ai/ 目录过滤是最后一道防线，私有仓库其他位置的敏感信息（如 .env、config.yaml）需自行清理
• 权限泄漏：脚本需 GH_TOKEN 环境变量或已认证的 gh CLI，存在凭证泄露风险
• 发布时序错误：若未先在私有仓库创建 Release，公共仓库将获得空 Release Notes，需人工补全