Fork Manager：专业级 Fork 工作流自动化工具
核心定位
Fork Manager 是一款面向活跃开源贡献者的进阶 Git 工作流管理工具，专注于解决"个人 Fork + 多 PR 并行开发 + 提前使用未合并代码"这一复杂场景。它通过结构化的配置管理、自动化状态追踪和交互式决策流，将原本需要大量手动操作的 fork 维护工作转化为可审计、可恢复的标准化流程。
核心用法
工具采用"仓库级配置隔离"架构，每个目标仓库在 repos/<name>/config.json 中维护独立配置，包含上游仓库映射、PR 编号与分支映射、本地补丁元数据等。主要命令包括：status 快速健康检查；sync 同步主分支；update-config 自动发现 PR 状态变更（含重新打开检测）；rebase-all 批量变基；build-production 构建聚合分支；review-closed 交互式处理关闭 PR；audit-open 冗余与过时检测；full-sync 一键完整工作流。所有操作自动维护 history.md 执行日志，支持断点续传。
显著优点
1. 闭环决策架构：对关闭 PR 不自动删除，而是触发结构化审查流程，支持 Drop/Keep as local patch/Resubmit/Defer 四种决策，避免代码意外丢失
2. 本地补丁原生支持：将 "PR 被拒但仍需使用" 的补丁作为一等公民管理，包含原因追踪、复审日期、上游状态监控
3. 智能状态恢复：自动检测 PR 被重新打开的情况，从 notes.droppedPatches 或 localPatches 无缝恢复至活跃追踪
4. 主动冗余检测：通过文件级交叉分析，识别上游已解决、外部重复、内部重叠等场景，提前避免维护负担
5. 生产级鲁棒性：强制 stash 保护未提交文件、--force-with-lease 防覆盖、checkpoint 断点机制、cron 模式的紧凑输出与时间预算
潜在局限
- 依赖外部工具链：必须预装
git和gh(GitHub CLI)，且gh需已认证 - GitHub 中心化：设计围绕 GitHub PR 模型，对 GitLab、Bitbucket 等平台需适配
- 交互式操作占比高：
review-closed、audit-open等核心流程需人工决策，难以完全无人值守 - 配置初始成本：每个仓库需手动建立 config.json，缺乏自动初始化向导
- 复杂合并冲突：生产分支构建时的冲突仍需人工介入，工具仅提供框架
适合人群
- 长期维护多个开源 Fork 的活跃贡献者
- 需要在生产环境提前使用未合并 PR 的团队
- 有大量 "被拒但仍需" 本地补丁的技术债务管理者
- 追求可审计、可追溯 fork 维护历史的组织
常规风险
1. 数据丢失风险：build-production 涉及分支删除重建，虽有 stash 保护，但 stash pop 失败可能导致工作区混乱
2. force-push 风险：--force-with-lease 虽比 --force 安全，但仍可能在竞争条件下丢失远程分支
3. 凭证泄露风险：gh 和 git 凭证由外部环境管理，技能本身不处理但仍依赖其安全性
4. 上游变更感知延迟：依赖定时 sync 发现上游变更，非实时监听
5. 配置漂移：手动编辑 config.json 可能导致与实际 Git 状态不一致