核心功能
Fork Manager 是一套完整的 Fork 仓库工作流管理方案，专为"既是贡献者又是使用者"的场景设计。核心能力覆盖四大维度：
1. 上游同步与分支维护
- 自动检测主分支落后上游的 commit 数量
- 安全同步（使用
--force-with-lease防止数据丢失） - 批量变基所有 PR 分支到最新上游
2. PR 全生命周期管理
- Open PRs：持续跟踪未合并贡献，自动检测是否需要变基
- Closed/拒绝 PRs：交互式决策流——彻底删除、转为本地补丁、或重新提交
- Merged PRs：自动清理并归档
3. 本地补丁系统（核心差异化）
支持将"上游拒绝/不修复但自身需要"的代码转为长期维护的本地补丁：
- 完整元数据追踪（原始 PR、关闭原因、保留理由、复查日期）
- 自动参与生产分支构建
- 定期复查机制（防止上游已修复但本地仍保留）
4. 智能审计与冗余检测
- Upstream 已解决：检测 PR 内容是否被上游其他提交覆盖
- 外部重复：发现他人提交的相似 PR
- 内部重复：检测自身多个 PR 间的文件冲突
显著优势
| 维度 | 优势 |
|------|------|
| **工作流完整性** | 覆盖从日常同步到季度清理的全周期，而非零散命令 |
| **数据安全** | 强制 stash 保护未提交文件、`--force-with-lease` 防覆盖、append-only 历史日志 |
| **决策可追溯** | `history.md` 完整记录每次操作，支持多 agent 协作 |
| **补丁治理** | 将"被拒绝的 PR"从负担转化为可管理的资产，含到期提醒机制 |
| **冲突预防** | 生产分支按"PR 优先、补丁次之"的顺序合并，最大化兼容性 |
潜在局限与风险
技术局限
- GitHub 依赖：重度依赖
ghCLI，暂不支持 GitLab/Gitee 等平台 - 交互瓶颈：
review-closed、audit-open等关键步骤需人工决策，无法完全自动化 - 冲突处理：复杂变基仍需手动介入，工具仅定位问题
操作风险
| 场景 | 风险等级 | 说明 |
|------|---------|------|
| `build-production` 强制重建 | 中高 | 删除并重建分支，虽有 stash 保护，但脚本中断可能导致状态混乱 |
| `rebase-all` 批量强制推送 | 中 | `--force-with-lease` 降低风险，但仍可能与他人协作冲突 |
| 本地补丁长期未 review | 低 | 可能积累技术债务，但功能正常 |
安全考量
- 需要 GitHub token 具备
repo权限读取 PR 详情 - 本地 config 存储完整仓库路径信息（无敏感凭据）
适合人群
核心用户画像：
- 向开源项目贡献 PR，但不能等待合并即需使用修复的开发者
- 维护长期 fork 的企业/团队（需保留私有补丁同时跟踪上游）
- 多 PR 并行开发者（5+ 开放 PR，需系统性管理变基冲突）
不适合：
- 纯使用者（无贡献需求）
- 完全自动化 CI/CD 场景（需人工决策环节）
- 非 GitHub 生态用户
常规风险提示
1. 首次使用前：确保 gh 已认证且有足够权限，建议先对非关键仓库测试
2. 生产分支：重建后需手动运行项目构建命令（工具会提醒但不执行）
3. 定期维护：建议每周运行 full-sync，避免变基债务累积
4. 多人协作：若团队共享 fork，需协调 productionBranch 更新时机