本文へ
ハクソク

世界を動かす技術を、日本語で。

Git-bug: Gitに組み込まれた分散型オフラインファーストのバグトラッカー

元記事: 原文(github.com)

概要

git-bug は、 Gitリポジトリ だけで動作する分散型バグトラッカー オフライン対応 や ベンダーロックイン防止 など多彩な特徴 CLI・Web・他ツールとの 柔軟な連携 が可能 GitHub/Jira 等、他トラッカーとの 橋渡し機能 も搭載 GPLv3 ライセンスで、貢献者・スポンサーも歓迎

git-bugとは

  • Gitに完全統合 されたバグトラッカー
  • Gitリポジトリ のみでバグ管理が可能
  • 分散型アーキテクチャ によるリモート連携
  • オフライン でもバグの閲覧・追加・編集が可能
  • ベンダーロックイン防止、バックアップも容易
  • 高速動作、バグ一覧や詳細表示がミリ秒単位
  • プロジェクト汚染なし、追加ファイル不要
  • 多様なUI (CLI・ターミナルUI・WebUI)とツール連携
  • 他バグトラッカーとのブリッジ 機能
  • インストール方法 はINSTALLATION.mdを参照

ワークフロー

  • ネイティブワークフロー
    • git bug push/pull でバグ情報をリモート同期
    • コード管理と同様の体験
  • ブリッジワークフロー
    • 他バグトラッカーと同期 (例:GitHub, Jira, GitLab, Launchpad)
    • git bug bridge pull/push でインポート・エクスポート
    • ターミナルやエディタ連携、オフライン利用も可能
  • Web UIワークフロー(開発中)
    • 外部OAuth認証 によるパブリックポータルを目指す
    • コントリビューション歓迎

CLIの利用例

  • 新しいユーザー作成
    • git bug user create
  • バグ追加
    • git bug add(エディタでタイトル・本文記入)
  • リモートへバグをプッシュ
    • git bug push [<remote>]
  • リモートからプル
    • git bug pull [<remote>]
  • バグ一覧表示
    • git bug ls
  • クエリでフィルタ・ソート
    • git bug ls "status:open sort:edit"
  • テキスト検索
    • git bug ls "foo bar" baz
  • 詳細表示・コメント・オープン/クローズ等
    • git bug <command> --helpで詳細確認

インタラクティブUI・WebUI

  • ターミナルUI
    • git bug termuiでバグの閲覧・編集が可能
  • Web UI
    • git bug webuiでリッチなWebインターフェース
    • バグ管理・コメント・ラベル編集等
    • コードブラウザ 機能(ファイルツリー・コミット履歴・差分表示)
    • GraphQL API による拡張性

ブリッジ機能

  • GitHub, GitLab, Jira, Launchpad とのインポート・エクスポート
  • 新規ブリッジ作成
    • git bug bridge new または
      git bug bridge new \
        --name=<bridge> \
        --target=github \
        --url=https://github.com/git-bug/git-bug \
        --login=<login> \
        --token=<token>
      
  • バグのインポート
    • git bug bridge pull [<name>]
  • 変更のエクスポート
    • git bug bridge push [<name>]
  • ブリッジ削除
    • git bug bridge rm [<name>]

内部仕様・拡張

  • データモデル・内部構造 はgit-bug specで詳細記載
  • DAGエンティティ形式、ID管理、バグエンティティ仕様
  • 独自実装やツール開発 にも活用可能
  • Bash, Zsh, fish, Powershell 用補完スクリプト
  • ManPages も提供

今後の予定・貢献

  • WebUIのパブリックポータル 化、ユーザー入力受付機能
  • その他新機能 はfeature matrix参照
  • コントリビューション歓迎、Matrixルームでの議論やPR受付
  • 開発環境構築・テスト手順 はCONTRIBUTING.md参照
  • WebUI開発 は専用READMEを確認

ライセンス・クレジット

  • GPLv3以降 ライセンス
  • ロゴ はViktor Teplov作、CC BY 4.0ライセンス
  • 貢献者・スポンサー への感謝
  • バッカーやスポンサー も随時募集中

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

誰かがfossil-scmのレッスンを受けてるみたい。すごくいい感じだね。

b4のメンテナーでLF ITのディレクター、コンスタンティン・リャビツェフが今週のKernel Recipesカンファレンスでb4とcgit(kernel.orgのフォーク)でのgit-bugサポートをデモしたよ。: https://b4.docs.kernel.org/en/latest/maintainer/bugs.html https://git.kernel.org/pub/scm/utils/b4/b4.git/bugs/ https://kernel-recipes.org/en/2026/2026/09/22/live-blog-day-...(宣伝失礼)

└

わお!これ、cgitに送られたの?

数ヶ月前にEpiqっていうのが投稿されてたよ: https://news.ycombinator.com/item?id=48155570 そこにコメントしたのは、10年以上前にこれらの人気が急上昇したことについてで、当時の問題点についての以前のコメントへのリンクも貼ったんだ(https://news.ycombinator.com/item?id=47956979)。それは設計上の問題で、実装の問題ではなかったから。例えば、3番目のポイントが一つの問題で、別のものが2番目のポイントでそれを解決しようとしたんだ。今はこの件を調べる時間がないけど、他の誰かには面白いかもしれないね。

└

あなたのリストの最初のポイント[1]を除けば、私の貢献は他のすべてに関わってるよ。リンクは今手元にないけど、githubに「rotsit」(何かの問題トラッカーの復讐)っていうのがある。‐----‐------ [1] 問題がブランチに結びついていることの全てのポイントだよ: あなたが見ているブランチで問題が解決済みとマークされていれば、そのブランチでも解決済みってこと。ブランチとは独立して問題を保存するってことは、どのブランチで壊れているかのメタデータも保存する必要があるってことだね。

これが新しい概念かもしれない人たちのために: 実は、こういう分散バグトラッカーが結構あるんだよ: https://news.ycombinator.com/item?id=22833037

└

どれも実際にはあんまりうまくいってないよ。このブログ記事は10年以上前のものだけど、状況はあまり改善してないね。 https://matej.ceplovi.cz/blog/current-state-of-the-distribut...

こんにちは、作者です。興味を持ってくれて嬉しいよ :-) ちなみに、これが私の近い将来のロードマップだよ: - ウェブUIが外部認証(GitHubのOAuthみたいな)を受け入れるようにして、公開ポータルにして外部とのやり取りを受け入れられるようにする - ウェブUIがgitリモートエンドポイントを公開する - アイデンティティを少し再構築して(おそらくpubkey配布のためにdid:plcに根付ける、BlueskyのアイデンティティシステムでATProtoとは関係なく)、リポジトリ間でアイデンティティをもっと自然に共有できるようにする - プルリクエストやCIのサポートを拡張する。これで、自己ホスティングも簡単にできるローカルファーストのフォージがかなり完成するよ。あと、注目を集めてる間に...これをフルタイムでやることを考えてるんだ。もし私がこれを続けるためのアドバイスや機会があれば教えてね!

└

Git-bug、めっちゃすごいね!GitSocialの作者だけど、あなたの意見を聞きたいな: https://gitsocial.org/

└

まずは、何かを形にしたことに大きなリスペクトを送るよ。すごく役立ちそうだね。

「これをフルタイムでやることを考えてるんだ。もし自分を支える方法やアドバイスがあったら教えて!」 「特別な機能セットと保証されたサポートを持つ“エンタープライズ”ティアを考えてみてもいいかも。ただ、俺の経験上、これをしっかり収益化するのはかなり難しいと思う。おそらく、そのソリューションの顧客層は、本当に必要になるまでソフトウェアにお金を使わないから(開発者に売るのは不可能って言うし、上司に売らなきゃいけない)。寄付モデルやクリエイター中心のアプローチがうまくいくかもね!」

└

他のシステムと統合して、gitメタデータを使って変更を追跡することについてどう思う?主にGerritを考えてるんだけど、あれはコードレビューや変更履歴を全部gitに保存してるからね。同じgitリポジトリにすべてを保持できるのはすごく魅力的だと思う。

└
  • webuiが外部認証(GitHubのOAuthみたいな)を受け入れるようにして、公共のポータルとして外部のやり取りを受け入れられるようにするのはどう? ForgeFedについて調べたことある?これは、Forgejoをベースにした異なるフォージが連携するための進行中の計画だよ。 https://forgefed.org/ それに、これもあるけど: https://indieauth.net/ まだ詳しく見てないけど、これらのうちのどれかを計画しているOAuth/アカウントシステムに統合できるといいな!
Hacker Newsで議論の続きを見る

同じ出典の記事