2026年9月25日，分布式Bug跟踪器git-bug再次登上Hacker News热榜。这个用Go语言编写的项目在GitHub已获得10251颗星标、325个派生，采用GPL-3.0许可，最新版本v0.11.0于9月22日发布。它的核心卖点很直接：把问题追踪完全嵌入Git仓库本身，开发者只需要一个Git仓库就拥有一个Bug跟踪器，无需额外部署任何服务端。
项目作者给出的特性清单覆盖了分布式协作的全部痛点。Bug数据完全嵌入Git，通过普通的Git远程进行推送与拉取，离线状态下照样可以阅读和编写Bug，版本库就是天然的全量备份从而防止供应商锁定，列出与打开Bug的延迟在毫秒级，并且不会在项目目录里污染任何文件。
桥接GraphQL API让旧系统数据可以平滑迁移
在工具链集成方面，git-bug提供CLI、终端与Web三种界面，并对外暴露GraphQL API，已有工具可以直接接入。对于不愿彻底抛弃既有平台的团队，项目提供桥接机制实现与其他Bug跟踪器的导入导出，可以把git-bug当作本地化操作界面与既有平台之间的同步层。
HN讨论中，Linux内核基础设施领域的反馈最有分量。b4维护者兼Linux基金会IT总监Konstantin Ryabitsev在Kernel Recipes大会上演示了b4与cgit中对git-bug的支持，并给出了b4官方文档的maintainer页面与内核源码仓库中的实现路径。这意味着git-bug的协议设计已经通过内核邮件列表工作流的检验，而非停留在概念演示阶段。
作者本人也在讨论中现身，并给出了明确的近期路线图。第一是让Web界面接受GitHub OAuth等外部认证，使其能作为公共门户接收外部交互；第二是让Web界面暴露一个Git远程端点；第三是略微调整身份体系，考虑以did:plc作为公钥分发机制，这是Bluesky的身份系统，但并不打算成为ATProto体系的一部分。
去中心化问题跟踪器十年后仍未出现成熟方案，但集成点已经变了
讨论中不可避免地出现了对这一类项目的历史回顾。有人指出十年前就出现过一批分布式Bug跟踪器，但状态并未明显改善，Fossil被反复作为成熟对照方案提及，评论者认为其证明了真正的难点在于聚集开发者兴趣而非技术实现。也有人从CRDT角度分析，指出多数项目用CRDT式机制合并工单变更，而Git本身已经提供合并能力，把工单存为普通Markdown反而可以同时解决代码与元数据的合并问题。
最有现实意义的判断来自商业化方向的讨论。评论者普遍认为纯开发者工具很难直接收费，但一个可行的细分市场正在出现：越来越多人用大模型开发业余项目，把工单和代码放在同一个仓库里，对LLM来说几乎是无摩擦的读取方式，甚至不需要额外部署MCP服务器。卖给开发者的业余项目而非日常工作，被指为更现实的路子。
git-bug的长期价值取决于身份体系与外部认证这两块能否按路线图落地，这决定了它能否从内核基础设施场景走进更广泛的公共项目协作。在此之前，它已经是一个值得认真评估的离线优先备份方案。