把问题追踪塞进 Git：git-bug 给不想被 SaaS 绑住的小团队

issue 为什么不该离代码太远

git-bug 的定义一句话能说清：分布式、离线优先的问题追踪工具，把 issue、评论等内容作为 git 对象（是对象，不是文件）嵌进仓库，可以推到一个或多个远端。仓库克隆到哪里，项目的来龙去脉就跟到哪里。

这是很多小团队真实遇到过的麻烦：代码在自己手里，工单和讨论记录却住在别人的服务器上。团队换工具、平台涨价、账号被封、API 政策变动，历史记录就变成了别人手里的数据。git-bug 的答案是让工单住在它本来该在的地方——和代码同一个仓库、同一套版本历史、同一份备份。

项目用 Go 写成，2018 年创建，目前约 1 万 star，GPL v3 许可，默认分支叫 trunk。存储走的是 git 对象，因此天然获得两件事：离线可用、可同步。没有网络的现场也能开单、写评论，回到有网环境再推拉。

官方列出的特性里，几条比较实用：列表和搜索是毫秒级；提供 CLI、TUI 和浏览器三种交互方式；最关键的是有第三方桥接，能与 GitHub、GitLab 双向同步。这意味着不必搞「一刀切迁移」——跟交付有关的事项留在仓库里，需要对外协作的继续走原来的平台。

git-bug 没有复杂的权限矩阵、没有服务台 SLA、没有跨组织的流程编排，它也不追求这些。它面向的是「项目不算大、但不愿把数据交出去」的场景。相比自建一套 issue 系统，部署成本低得多：一个 Go 二进制，放在仓库旁边就行。

更值得注意的其实是它的存储哲学。把工单变成版本化对象之后，一条 issue 是怎么演化的就留了痕：谁在什么时候改了标题、加了标签、关了又开。这种可审计的历史，在自建系统里通常要单独设计，在 git 里是免费的。

乙方做项目最怕两件事：需求聊散了，验收时扯不清；工具链换了，历史记录丢了。把需求变更、缺陷、验收讨论都记进项目仓库，交付时随代码一起打包给客户，或者留在自己的私有远端，是种很省事的做法——三年后回头看，为什么这么改、当时谁定的，都能查得到。

起步动作可以很小：挑一个正在维护的项目初始化 git-bug，把接下来两周的新问题记进去，同时用桥接同步到现有的 GitHub 或 GitLab 仓库。跑一个月，再决定要不要扩大范围。工具的价值从来不在功能列表里，而在它是否真的减少了沟通成本。