Git仓库批量运维工具

多仓库巡检的重复劳动

手里维护十几个甚至几十个 CNB 仓库时，逐个打开页面确认「哪个仓库最近还有提交、哪个分支已经半年没人碰」是一件很消耗精力的事。手工巡检的问题不只是慢：不同人判断标准不一致，有的习惯看默认分支，有的习惯看全部分支；漏看也很常见，往往直到依赖它的人报错才发现某个仓库已经处于无人维护的状态。

git-ops-toolkit 要解决的是这类批量、周期性、标准统一的仓库状态确认问题，而不是替代日常的代码审查或发布流程。

核心能力与关键步骤

这个技能围绕 CNB API 做两件事：拉取仓库列表，以及逐个读取分支与提交信息。具体流程如下：

• 调用 GET /user/repos 获取当前 token 可见的仓库集合，作为巡检范围。
• 对每个仓库调用 GET /{repo}/-/git/branches 获取分支列表，再调用 GET /{repo}/-/git/commits 读取提交记录。
• 以最后提交时间作为主要活跃度依据，同时结合分支数量与最近提交分布，把仓库归类为活跃、不活跃或 stale。
• 汇总为一份报告输出，方便直接贴进值班记录或 issue 跟踪。

认证方式是在请求头携带 Authorization: Bearer {CNB_TOKEN}，因此 token 的权限范围直接决定了能看到哪些仓库。

适用边界与注意点

有几个地方需要提前想清楚：

1. 只覆盖 CNB 平台。技能的所有接口都指向 CNB，不存在 GitHub 或 GitLab 的适配器，跨平台统一巡检需要另找方案。
2. 活跃度不等于健康度。最后提交时间能反映有没有人在动代码，但无法反映提交质量、是否有人 review、issue 是否堆积。把「stale」直接读成「该归档」是有风险的。
3. 权限受限的仓库会出现在列表里却读不到细节。如果 token 没有某个仓库的读取权限，分支和提交接口会失败，报告中该仓库的状态可能不完整。
4. 没有内置调度。资料中没有提到定时触发或 webhook 机制，「定期巡检」意味着需要外部 cron 或脚本驱动。

适合的使用姿势是：把它当成巡检流水线里的一个步骤，由外部调度拉起，产出报告后再由人判断哪些仓库需要清理、归档或分配维护者。