技能介绍

解决什么问题

仓库分支一多，劣化往往来得悄无声息：某个分支三个月没人碰，合并时才发现早已偏离主干；两个分支各自提交，直到 MR 阶段才暴露冲突；主干与特性分支的分叉点散落在不同工具里，很难快速定位。人工排查意味着在 git log、git branch -r、GitHub 页面之间反复横跳，结论既不统一也难以复现。

核心能力与工作流程

这个技能把分支拓扑分析交给程序化处理，核心能力有三：

分支拓扑分析：基于 libgit2 绑定直接读取仓库对象模型，重建分支与提交的关系图，而不是逐条执行 git 命令拼接结果。
问题识别：标记三类典型劣化信号——长期无活动的陈旧分支（stale branches）、存在合并冲突的分支对、以及与主干产生分叉点（divergence points）的提交序列。
远端数据补全：通过 GitHub GraphQL API 拉取 PR 合并状态、保护分支规则等仓库侧元数据，与本地分析结果交叉验证。

典型流程是：定位目标仓库 → 用 libgit2 解析引用与提交图 → 结合 git log 解析补充提交历史语义 → 调用 GraphQL API 补充 PR 与冲突状态 → 输出分支体检报告。

适用边界与注意事项

仅限 GitHub 托管仓库：GraphQL API 部分依赖 GitHub 侧数据，其他平台（GitLab、自建 Gitea 等）无法获得同等的 PR 级信息。
运行时依赖：上游说明要求本机具备 Python、Node.js 或 Ruby 环境之一，缺少运行时会直接失败。
libgit2 与 git CLI 的边界：两者在子模块、LFS 指针、partial clone 等边缘场景下的行为不完全一致，遇到异常仓库结构时建议用原生 git 复核。
非策略执行工具：它输出的是分析结论，分支保护与强制合并门禁仍需在平台侧配置，不能把它当作 CI 的替代。
上游文档与代码分别来自 libgit2 官方仓库与独立 skills 仓库，遇到行为差异以实际运行环境为准。