Issue tracker は本来、GitHub や GitLab のようなサービスの中で使うものだと思われがちだ。だが git-bug は、その前提をひっくり返している。Git リポジトリそのものにバグ管理を埋め込み、オフラインでも使え、必要なら他の tracker ともつながる。しかも「プロジェクトを汚さない」「ベンダーロックインを避ける」といった、開発者が地味に気にする点を正面から押し出しているのが面白い。今回は、このリポジトリが何を目指しているのかを整理しつつ、その設計がどこまで現実的かを見ていく。
元記事は、git-bug というオープンソースのプロジェクトを紹介する GitHub リポジトリの README だ。説明はかなりはっきりしていて、git-bug は「Distributed, offline-first bug tracker integrated in git」、つまり Git に統合された分散型・オフライン優先の bug tracker だと名乗っている。
README では、この仕組みの特徴をいくつか並べている。まず、バグ情報は Git リポジトリに組み込まれるので、追加の専用サービスがなくても tracker を持てる。通常の git remote を使って bug の push / pull ができるため、コードと同じ感覚でやり取りできる。ネットにつながっていない環境でも書き込みや閲覧ができるのも売りの一つで、飛行機の中や海の下でも使えると冗談まじりに書かれている。さらに、外部サービスが止まったり、方針が変わったりしても、手元に完全なバックアップが残るため、vendor lock-in を避けられるという。
性能面でも自信があるようで、bug の一覧表示や新規作成はミリ秒単位で動くと説明している。加えて、プロジェクトのディレクトリに新しいファイルを散らばらせないので、作業ツリーを汚さない。使い方も柔軟で、CLI、terminal UI、web UI から操作でき、GraphQL API で既存ツールとつなぐこともできる。さらに GitHub、GitLab、Jira、Launchpad との bridge を持っていて、他の tracker からの import / export も可能だ。
README には具体的な操作例もある。git bug user create で identity を作り、git bug add で bug を追加する。git bug push と git bug pull で remote と同期し、git bug ls で一覧を出し、status:open sort:edit のような query で絞り込める。show、comment、open、close といった操作も用意されている。対話的に使う git bug termui もあり、git bug webui を起動すれば、issue の閲覧・検索・編集に加えて、コードブラウザとして file tree、syntax-highlighted files、commit history、diff まで見られる。内部実装についても、on-disk format の spec や data model の説明が用意されているので、別実装や直接データを読むツールを作ることも想定している。開発中の機能としては、public portal として使える web UI などが挙げられている。
まず引っかかるのは、「なぜ bug tracker まで Git に入れるのか」という点だ。普通は issue 管理は SaaS に任せれば済むし、わざわざ別の仕組みを増やす必要はないように見える。だが git-bug の発想は、コードと同じ保存・同期モデルを issue にも適用したい、というところにある。ここはかなり筋がいいと思う。Git はそもそも分散管理が得意で、履歴が手元に残り、remote 同期の考え方も開発者に馴染んでいる。そこへ bug 情報を乗せれば、「コードは Git、課題は別サービス」という分断をかなり減らせるからだ。
ただし、これは理想だけでは回らない。issue tracker は個人のメモではなく、プロジェクト参加者全体の共有インフラだ。だからこそ、Web UI や OAuth を使った public portal まで視野に入れているのは重要だと思う。コントリビュータ全員が CLI に慣れているわけではないし、外部の利用者が bug を投稿する場面では、ブラウザから自然に触れる入口が必要になる。README がそこを WIP として明示しているのは誠実で、同時に難所でもある。Git に載せるだけでは足りず、参加体験をどう設計するかが本番になる。
README の中で一番強い言葉は、実は「offline-first」かもしれない。飛行機の中で使える、というのは単なる便利機能に見えるが、実際にはもっと大きい。ネットがあることを前提にした SaaS だと、障害や規約変更、サービス終了のたびにユーザーは振り回される。git-bug はそこに対して、「手元に完全なバックアップがある」と言っている。これは単なる可用性の話ではなく、データの主権をどこに置くか、という話だと思う。
とはいえ、オフライン優先の仕組みは、衝突解決や同期の複雑さを必ず連れてくる。複数人が同じ bug を編集したとき、どう merge するのか。どの操作を後勝ちにするのか。README はそこを詳細に語っていないが、分散型 tracker である以上、避けて通れない。ここで大事なのは、Git という名前が付いていても、コードの merge と issue の merge は同じではないことだ。issue は自然文が中心で、状態遷移もある。だから、見た目はシンプルでも内部の設計はかなり厳しいはずだ。オフライン優先を掲げるなら、その複雑さを隠すのではなく、どこまで吸収できるかが評価の分かれ目になる。
git-bug は操作手段を一つに絞っていない。CLI だけでなく terminal UI、Web UI、GraphQL API まである。普通なら「散らかっている」と見られそうだが、これはむしろ現実的だと思う。開発者の仕事場は一枚岩ではないからだ。普段はターミナルにいる人もいれば、レビューのついでにブラウザで issue を開く人もいる。さらに、既存のツールに組み込みたい場合は API が欲しい。どれか一つだけだと、結局どこかで使われなくなる。
特に面白いのは、Web UI が単なる issue viewer ではなく、コードブラウザも兼ねている点だ。file tree、syntax highlighting、commit history、diff を同じ画面で扱えるなら、「issue を見に行ったらソースも確認する」という流れがかなり自然になる。issue と code を別画面で行き来する摩擦を減らす狙いが見える。これは地味だが効く設計だと思う。一方で、こういう多機能化は保守コストも上げる。git-bug が長く生きるかどうかは、機能を増やすことより、どこを削らないかにかかっているのではないか。
README には bridge 機能があり、GitHub、GitLab、Jira、Launchpad と import / export できると書かれている。これも大事な点だ。新しい tracker は、思想が優れていても「今あるデータをどう持っていくか」で止まりがちだからだ。既存 tracker との橋があると、完全移行を迫らずに試せる。個人のローカル remote として始め、必要なら外部サービスと同期する、という導線はかなり現実的だと思う。
ただ、ここでも万能視は危ない。異なる tracker 間で、issue の状態、ラベル、担当者、コメント、通知の扱いは揃わないことが多い。bridge は便利だが、完全な互換性を期待すると痛い目を見るタイプの機能でもある。だからこそ README が feature matrix や bridge documentation を案内しているのは正しい。どこまでできて、どこから先は人が調整するのかを明示しているからだ。git-bug は「既存サービスを全部捨てろ」と言っていない。その代わり、手元にデータと同期手段を持てるようにする。思想としてはかなり穏健で、だからこそ試しやすい。
参考: GitHub - git-bug/git-bug: Distributed, offline-first bug tracker integrated in git
