10,634 颗星、16 个月憋出 v0.11.0：git-bug 把 bug 追踪塞进了 Git 仓库本身

器匠·开发者工具 内容创作者 2026-09-28 1137 阅读

一个 bug 追踪器，不加数据库、不建服务器、不注册账号，直接塞进你的 Git 仓库里——这就是 git-bug 在做的事。它在 2018 年 7 月立项，如今 10,634 颗星、332 个 Fork，2026 年 9 月 22 日刚发出 v0.11.0，距离上一个正式版 v0.10.1 已经过去整整 16 个月。这次它不是修修补补，而是把 Web UI 从零重写，并顺手做了一次”正确性”大扫除。

它到底把 issue 存在哪

理解 git-bug 的关键，是明白它没有中央数据库。每条 bug、每次评论、每次状态变更，都被写成 Git 对象，挂在仓库自身的引用体系下。所以：

  • 推送代码的 git push，同样能推送 bug；git bug push / git pull 走的就是你熟悉的远程。
  • 飞机上、内网里、断网环境下，照常读写 issue，联网时再同步。
  • 不存在”服务商跑路了、我的 issue 也跟着没了”这种事，数据本身就是仓库的一部分。

官方 README 把它总结成四条：完全集成进 git、分布式协作、离线可用、防止供应商锁定。这四句话听起来像口号，但在具体实现上是成立的。它用 Git 的合并机制处理多端冲突，用逻辑时钟确定操作顺序，非冲突变更自动合并、真冲突才让人介入。

v0.11.0 到底改了什么

最显眼的是 Web UI 完全重写（git bug webui 启动），由 @sandhose 和 @MichaelMure 主导。新的界面支持浏览、搜索、过滤、分页，能新建 issue、评论、改标题、改标签和状态，还能看用户主页。过滤条件直接写进 URL，任何一个视图都是一条可以发出去的链接。四套主题（明/暗 × 柔和/硬朗），外加多仓库切换器。

顺带它把自己变成了一台代码浏览器：文件树、语法高亮、可链接的行号范围、markdown 渲染、按文件看提交历史、可折叠的 diff。这些能力全部通过同一个 GraphQL API 暴露——UI 能看到的，你自己的工具也能查到。

不那么显眼、但可能更重要的一半，是”正确性”修复。发布说明里承认缓存层存在一系列竞态和原子性问题，其中两个是用户长期上报却一直没解释清楚的：#1582（推送到 GitHub 再拉回来，每条评论都会重复一遍）和 #1003（git bug user 无法采纳身份）。另外还有一个向前兼容的改动：现在遇到不认识的 operation 类型会原样保留，而不是悄悄删掉——这直接消除了未来扩展数据模型时的兼容性雷区。

安装方式也换了 GoReleaser 构建：提供 deb/rpm/apk/Arch 原生包，校验和用 keyless cosign 签名，每个 release 带 SBOM 和构建溯源证明；Apple Silicon 的 macOS 版本回来了，Windows on ARM 和 BSD 也一并支持。

真实使用门槛，别被”零依赖”骗了

git-bug 不是装上就能无脑用。几件事得先想清楚：

  • 它不污染项目目录，数据存在 .git/git-bug 下而不是你的工作区——这点对洁癖很友好，但也意味着你得知道去哪找它。
  • 搜索索引格式在 v0.11.0 变了（bleve v1 → v2），升级会自动重建；但降级不会，需要手动删掉 .git/git-bug 让旧版本重建。好处是索引体积从约 51 MiB 压到不足 4 MiB。
  • go install 不再带 Web UI。以前编译好的前端是提交进仓库的，现在不是了。用 go install 装出来的二进制仍然能跑 CLI，但 git bug webui 会告诉你没有界面。想要 Web UI 就下官方 release，或者 make build。
  • 破坏性改动还包括：git bug commands 被移除，git bug webui --host 改名成 --bind，linux/386、linux/s390x 等平台构件被砍。

换句话说，”零依赖”指的是运行时不需要数据库和服务器，不是指不需要你花时间理解它的数据模型和迁移规则。

谁适合，谁不适合

适合： 已经重度使用 Git、希望 issue 与代码同仓同版本的个人开发者和小团队；需要在离线、内网、无 SaaS 可用的环境里管理问题的场景；把数据主权看得很重、不想被平台锁死的项目；需要从 GitHub/GitLab/Jira/Launchpad 双向导入导出、又想保留一份本地副本的人（bridge 功能齐全，配置用 git bug bridge new 即可）。

不适合： 需要开箱即用的公开 issue 门户的团队——官方明确说公开 Web UI 需要的 OAuth 外部认证”还没有”；依赖看板、甘特图、SLA 报表等重型项目管理的组织；完全不熟 Git 的非技术成员；以及希望”下载即双击可用”的普通用户，因为它的主界面仍是 CLI 和 TUI。

该不该跟进，看你的仓库结构

git-bug 的价值不在”又一个 bug 追踪器”，而在它把 issue 变成了版本化、可合并、可回滚的 Git 数据。如果你的项目本来就把一切交给 Git，它几乎是零成本的一条分支；如果你的团队离不开看板和公开门户，它现在还不是那个答案。

想动手的话，建议这样起步：先在一个个人小仓库里 git bug user create 建身份、git bug add 开一条 bug，用 git bug termui 逛一圈感受交互；确认顺手后，再用 git bug bridge new 接一个 GitHub 仓库做双向同步试验（注意 #1582 的评论重复问题已在 v0.11.0 修复，尽量用最新版）。要写自己的工具或做二次实现，直接读新出的格式规范 git-bug/spec。

评论区

0 条评论

登录后可评论。

器匠·开发者工具 1137 阅读