Deploy Public

核心用法

deploy-public 是一个专为 GitHub 仓库设计的双向同步脚本，主要解决私有开发仓库与公共开源镜像之间的代码发布问题。用户只需执行单条命令即可自动完成：克隆公共仓库、复制代码（自动排除 ai/ 等敏感目录）、创建分支提交、发起 Pull Request、执行合并操作，并最终同步 GitHub Releases 的发布说明。

脚本依赖 git、gh（GitHub CLI）和 bash 环境，要求目标公共仓库已预先创建，且命名遵循 *-private 的对应关系。使用时需严格遵循三步流程：先合并私有仓库 PR、再运行 wip-release 创建带说明的 Release、最后执行 deploy-public 同步至公共仓库，否则公共 Release 将缺失说明内容。

显著优点

• 隐私保护设计：自动过滤 ai/ 目录，避免内部 AI 提示词或敏感配置泄露
• 流程自动化：将原本需要多步手动操作的发布流程浓缩为单次命令执行
• Release 同步：独创性地将私有仓库的 Release 说明自动迁移至公共仓库，保持发布信息一致性
• 分支策略安全：强制使用常规合并（regular merge），避免 squash 导致历史丢失

潜在缺点与局限性

• 命名耦合：要求仓库严格遵循 *-private 命名约定，灵活性受限
• 前置依赖繁琐：必须预先安装 GitHub CLI 且完成认证，三步流程顺序不可颠倒
• 单点故障风险：脚本失败可能导致公共仓库处于不完整状态（如 PR 已创建但未合并）
• 无回滚机制：一旦合并完成，错误同步的内容需手动回退

适合人群

• 采用 "open core" 或 "private development + public release" 模式的开源维护者
• 需要定期从内部仓库向 GitHub 公开镜像推送代码的 DevOps 工程师
• 使用 AI 辅助开发但需隔离提示词仓库的团队

常规风险

• Token 泄露：gh CLI 依赖的 GitHub Token 需具备写权限，存在误配置导致越权风险
• 敏感数据残留：虽然过滤 ai/ 目录，但其他路径的硬编码密钥仍需人工审核
• 分支冲突：若公共仓库存在未预期变更，自动合并可能产生冲突中断流程
• Release 覆盖：同步操作会覆盖公共仓库现有 Release，需谨慎确认版本号