KechuAI

gh-dashboard（gitdeck）：跨仓库聚合的 GitHub/Web 仪表板

GitHub
仪表盘
开源
React
开发者工具
自托管
2026/9/29
·

阅读时间: 大约 8 分钟

gh-dashboard（gitdeck）：跨仓库聚合的 GitHub/Web 仪表板

gitdeck 定位：一个界面里跨多个 GitHub/GitLab/Forgejo 账号浏览仓库、Issue、PR、流量与 CI

GitHub 这几年把 UI 越加越复杂，但跨仓库聚合一直是短板：同时维护十几个项目的人，不得不在一堆标签页之间来回跳。gh-dashboard（仓库现已改名 gitdeck，debba/gitdeck）是一个开源自托管仪表板，把分散在 GitHub 各页面的数据聚到一个 Web 界面。它和终端工具 gh-dash 思路类似，但用 Web 而非 TUI，受众更广。本文基于其 README 做分析。

一、它解决什么问题

跨仓库开发者的典型痛苦：想知道「我所有仓库里哪些 Issue 该处理、哪些 Dependabot 告警没人管、最近哪些 repo 有动静、每个仓库流量怎样」——GitHub 官方没有一个跨 repo 的总览页。gitdeck 直接把这些做成若干视图：

  • Repositories：分页网格，含描述、语言、star/fork、open issue、最近 push、每个 repo 的健康分；可按组织/语言/可见性过滤；
  • Issues / Pull Requests：跨仓库列表，统一过滤侧栏，方便跨项目 triage；
  • Insights：全 repo 告警总览（「issue 需要关注」「安全告警待处理」「X 天无 push」），每个 repo 给 Strong/Watch/Risky 状态；
  • Alerts：Dependabot 与 code scanning 告警的专门视图；
  • Daily digest：每个 repo 当天动静（star/fork/issue）的短摘要，可复制成 Markdown，配了 OpenAI key 还能自动生成叙述；
  • Board：看板视图，把 Issue 拖进 Backlog/To-do/In progress/In review 等列。

点开单个仓库，还有 overview、安全、Actions、PR/Issue、releases、forks、14 天流量（views/clones、来源、热门路径）、mentions、dependents、语言与 star/fork 趋势、contributors。

二、架构：后端代理 + 前端 SPA

gitdeck 的 OAuth Device Flow 说明：token 存在 ~/.gitdeck，浏览器接触不到

它是单仓库双进程：

  • 后端（Node HTTP）：处理 GitHub OAuth（Device Flow）、代理所有 REST/GraphQL 调用、磁盘缓存响应、对外只暴露 /api/*；GitHub token 存在本地 ~/.gitdeck/，绝不暴露给浏览器；
  • 前端：React 19 + Vite 8 SPA，调后端 /api/*；生产环境由 Node 进程一并托管。

OAuth 用 Device Flow：后端给你一个短码和 github.com/login/device 链接，你在 GitHub 批准后，后端拿 token 并存在本地。默认 scope 是 repo read:org project:read user:user:email，可用 GITHUB_OAUTH_SCOPES 收窄。这套「token 留在本机后端、浏览器只碰 JSON API」的设计，比把 token 塞浏览器本地存储要稳妥。

三、必须自己评估的边界

  1. 它是「聚合查看器」，不是「GitHub 替代品」。gitdeck 读 API 做展示与轻量 triage（看板、列表），但深度编辑、CI 重跑细节、复杂 PR 审查仍要回 GitHub。它省的是「跨仓库跳转」，不是「操作 GitHub」。

  2. 数据靠 API + 磁盘缓存，实时性有延迟。后端缓存响应，这是为了不触发 GitHub API 限流，但也意味着你看到的不是毫秒级实时；流量数据 GitHub 本身就只提供 14 天窗口。

  3. 仓库刚改名/项目很年轻：Koala 条目名 gh-dashboard，仓库已更名 gitdeck；issues 2、PR 1，说明还在早期。README 也坦言「初始脚手架由 Claude Code 辅助生成，此后由人评审维护」——AI 生成代码的项目，长期维护质量要观察。

  4. 多 forge 支持是渐进的：宣称支持 GitHub/GitLab/Forgejo，但 views 的深度（流量图、Dependabot、code scanning）明显围绕 GitHub 设计，GitLab/Forgejo 能拿到多少对应数据取决于各自 API，别假设对等。

  5. AI 叙述是可选增强：Daily digest 的 OpenAI 生成需要自己配 key，属于锦上添花，不是核心价值。

四、适用与不适用场景

适合： 同时维护多个 GitHub 仓库、想要一个跨 repo 总览与告警面板的个人/小团队；喜欢自托管、不愿把仓库数据交给第三方 SaaS 的人；需要每天一份 Markdown 摘要、或用看板跨项目管 Issue 的人。

不适合： 只在一两个 repo 上工作、GitHub 原生页够用的人；需要企业级多团队权限、SAML、审计的场景；期待它替代完整 GitHub 操作的人。

五、客观分析：优势与意义

优势： 跨仓库聚合打中了 GitHub 原生体验的真实空白；视图覆盖全（仓库/Issue/PR/流量/CI/告警/看板/日报）；token 不出本机的后端代理设计务实；React 19 + Vite 现代栈，自托管轻量；支持 GitHub 之外的 GitLab/Forgejo。

局限： 缓存带来的非实时；项目年轻、刚改名；跨 forge 能力不对等；本质是只读聚合 + 轻 triage。

gitdeck 的意义在于：当开发者的工作从「一个仓库」变成「一片仓库」，聚合层就成了必需品。GitHub 官方短时间内未必会做完美的跨 repo 总览，这正是开源仪表板的机会。它不惊艳，但把「我今天该看哪些 repo、哪些告警没人管」这件事一个页面说清了——对被标签页淹没的多仓库开发者，值得自托管一个。

参考来源