git-bug: Bug Tracker Terdistribusi yang Tinggal di Dalam Git

Ada satu kebiasaan yang hampir selalu muncul saat sebuah proyek mulai serius: bug tracker dipindahkan ke layanan pihak ketiga. Issue pindah ke GitHub, GitLab, atau Jira. Sejak itu, riwayat bug dan riwayat kode hidup di dua tempat berbeda, dengan dua sistem autentikasi, dua format data, dan dua cara untuk mati.

git-bug menawarkan jalan lain. Ini bug tracker yang tinggal di dalam repository git itu sendiri. Repositori proyek sudah cukup untuk punya bug tracker, tanpa layanan tambahan, tanpa database terpisah, dan tanpa file yang mengotori struktur proyek.

Apa itu git-bug

git-bug adalah bug tracker terdistribusi yang terintegrasi penuh dengan git. Beberapa sifat yang diklaim proyek ini di dokumentasinya cukup spesifik, jadi layak dikutip apa adanya.

• Terintegrasi penuh dengan git: hanya perlu repositori git untuk punya bug tracker.
• Terdistribusi: kolaborasi memakai remote git biasa, push dan pull bug seperti push dan pull kode.
• Bekerja offline: bug tetap bisa dibaca dan ditulis tanpa koneksi.
• Mencegah vendor lock-in: kalau layanan biasa down atau berubah arah, sudah ada salinan lengkap di sisi pengguna.
• Cepat: menampilkan daftar bug atau membukanya berlangsung dalam hitungan milidetik.
• Tidak mengotori proyek: tidak ada file yang ditambahkan ke struktur proyek.
• Terintegrasi dengan tooling: UI yang dipakai bebas, entah CLI, terminal, atau web, dan bisa diintegrasikan lewat CLI atau GraphQL API.
• Punya bridge ke bug tracker lain: impor dan ekspor ke tracker lain.

Angka proyeknya juga tidak kecil. Saat artikel ini ditulis, repository git-bug mencatat sekitar 10.400 bintang dan 326 fork, dengan riwayat lebih dari 2.694 commit. Lisensinya GPLv3 atau lebih baru, dan proyek ini dikaitkan dengan Michael Muré sebagai pemelihara utama.

Kenapa pendekatan ini masuk akal

Masalah utama bug tracker terpusat bukan soal fitur. Masalahnya adalah kepemilikan dan ketergantungan. Begitu issue hidup di layanan orang lain, tiga hal ikut bergantung pada layanan itu: ketersediaannya, kebijakan harganya, dan arah produknya.

Untuk proyek yang dikerjakan satu orang atau tim kecil, ini beban yang sering tidak disadari sampai layanan tersebut berubah. Harga naik, fitur dihapus, API ditutup, atau akun bermasalah. Pada titik itu, riwayat bug yang seharusnya jadi aset proyek justru jadi sandera.

Karena git-bug menyimpan data di dalam git, sifat-sifat git ikut terbawa. Setiap remote git jadi salinan penuh. Kalau satu remote hilang, remote lain masih punya datanya. Kalau proyek berhenti memakai git-bug, datanya tetap ada dan formatnya dispesifikasikan secara terbuka, sehingga bisa dibaca tool lain.

Ada satu detail yang sering jadi kekhawatiran dan dijawab langsung oleh proyeknya: git-bug tidak menambahkan file ke struktur proyek. Jadi tidak ada direktori .bugs yang muncul di root repository, dan tidak ada file yang ikut terlihat saat orang lain menjelajahi kode.

Cara memakainya dari terminal

Alur dasar git-bug mengikuti kebiasaan git. Langkah pertama membuat identitas, karena setiap entri perlu tahu siapa penulisnya:

git bug user create

Setelah itu, membuat bug baru sama sederhananya dengan membuka editor untuk menulis judul dan pesan:

git bug add

Bug baru itu masih lokal. Untuk mengirimnya ke remote, jalankan push, dan untuk menarik perubahan dari orang lain, jalankan pull:

git bug push [<remote>]
git bug pull [<remote>]

Menampilkan daftar bug memakai perintah git bug ls. Yang membuat bagian ini berguna adalah query-nya. Daftar bisa disaring dan diurutkan dengan sintaksis yang mirip query bahasa manusia:

git bug ls "status:open sort:edit"

Pencarian teks bebas juga didukung, dengan kata kunci tambahan di luar tanda kutip:

git bug ls "foo bar" baz

Dari situ, perintah seperti show, comment, open, dan close dipakai untuk membaca dan mengubah bug. Semua perintah punya bantuan sendiri lewat git bug nama-perintah --help.

Dua antarmuka lain: terminal dan web

Bagi yang lebih suka menelusuri tanpa menghafal perintah, ada terminal UI interaktif:

git bug termui

Yang lebih menarik adalah web UI:

git bug webui

Web UI ini dibundel di dalam binary Go yang sama dan disajikan oleh server HTTP lokal. Ia berbicara ke backend lewat GraphQL API, dan skema API-nya tersedia untuk dirujuk. Fitur yang disediakan mencakup penelusuran, pencarian, penyaringan issue, pembuatan issue baru, komentar, serta pengeditan judul, label, dan status.

Ada nilai tambah yang jarang disebut: web UI ini sekaligus berfungsi sebagai penjelajah kode untuk repository tersebut. Ia menyediakan pohon file, file dengan penyorotan sintaksis, riwayat commit, dan diff. Untuk proyek yang bug tracker dan kodenya memang satu paket, ini kombinasi yang rapi.

Bridge ke bug tracker lain

Bagian ini yang membuat git-bug masuk akal untuk tim yang tidak bisa sepenuhnya meninggalkan layanan lama. git-bug punya bridge untuk GitHub, GitLab, Jira, dan Launchpad, dengan matriks fitur yang merinci apa saja yang didukung tiap bridge.

Konfigurasi bridge bisa dilakukan secara interaktif:

git bug bridge new

Atau manual dengan parameter lengkap:

git bug bridge new --name=NAMA_BRIDGE --target=github --url=https://github.com/git-bug/git-bug --login=LOGIN --token=TOKEN

Setelah terpasang, impor bug dilakukan dengan git bug bridge pull, mengirim perubahan kembali dengan git bug bridge push, dan menghapus bridge dengan git bug bridge rm. Perlu diperhatikan bahwa parameter token di atas diketik sebagai argumen command line. Dari sudut kebersihan kredensial, pola itu kurang ideal karena token bisa tertinggal di riwayat shell. Untuk pemakaian nyata, lebih aman memakai konfigurasi interaktif atau menyimpan kredensial lewat mekanisme yang tidak meninggalkan jejak di riwayat perintah.

Dengan bridge, git-bug bisa diposisikan sebagai antarmuka lokal. Kerja harian dilakukan dari terminal atau editor, sementara sinkronisasi ke tracker resmi tim tetap berjalan. Ini juga yang membuat klaim "tetap bekerja offline" punya arti praktis: perubahan yang dibuat tanpa koneksi bisa dikirim saat koneksi tersedia.

Format data dan spesifikasinya

Salah satu hal yang membedakan git-bug dari eksperimen serupa adalah format on-disk-nya dispesifikasikan secara formal. Spesifikasi itu mencakup format entitas DAG, identitas, dan entitas bug. Dokumen ini ada supaya orang lain bisa menulis implementasi lain atau membuat tool yang membaca data git-bug secara langsung.

Ini penting untuk umur panjang data. Bug tracker yang datanya hanya bisa dibaca oleh satu binary adalah ketergantungan baru, hanya dengan bentuk berbeda. Spesifikasi terbuka membuat datanya tetap bisa diakses walau proyeknya berhenti dikembangkan.

Struktur repository-nya sendiri cukup jelas dari nama direktorinya: ada api, bridge, cache, commands, entities, entity, query, repository, termui, dan webui. Pemisahan ini memperlihatkan bahwa bridge dan antarmuka memang lapisan terpisah di atas inti datanya, bukan tambalan.

Instalasi dan pemeliharaan

Panduan instalasi lengkap tersedia di repository, termasuk cara membangun dari sumber dan cara memverifikasi hasil instalasi. Ada juga completion untuk bash, zsh, fish, dan powershell, serta man page, sehingga alat ini bisa dipakai dengan nyaman tanpa menghafal seluruh perintah.

Untuk pemeliharaan, sifatnya sederhana: selama git masih dipakai untuk kode, git-bug ikut terpelihara. Tidak ada layanan yang perlu diperbarui, tidak ada langganan yang perlu diperpanjang, dan tidak ada akun yang perlu dijaga. Semua yang perlu diamankan sudah diamankan bersama repository itu sendiri.

Yang belum selesai

Web UI saat ini ditandai sebagai work in progress. Tujuannya adalah menjadikannya portal publik yang menerima autentikasi OAuth eksternal sehingga orang luar bisa melaporkan masalah, mirip tracker publik pada umumnya. Kondisi sekarang belum sampai ke sana, dan proyeknya terbuka soal itu serta mengundang kontribusi.

Dokumentasi proyek juga menyebut satu fitur yang direncanakan dengan nada bercanda, yaitu "inflatable raptor". Bagian itu jelas bukan janji teknis, tapi menandakan bahwa halaman rencana fiturnya memang mencantumkan hal-hal yang belum jadi prioritas.

Untuk siapa alat ini cocok

git-bug paling masuk akal untuk proyek yang ingin punya tracker tanpa menambah layanan baru: proyek personal, proyek internal tim kecil, atau proyek yang sebagian besar kerjanya dilakukan offline atau di lingkungan terbatas.

Untuk proyek open source besar yang mengandalkan kontribusi dari orang luar, situasinya berbeda. Tracker publik yang bisa diakses siapa saja masih jadi keunggulan layanan terpusat, dan bagian itu belum selesai di git-bug. Bridge menutup sebagian celah, tapi bridge tetap berarti ada dua tempat yang harus disinkronkan.

Yang jelas, pendekatan "data dulu, layanan kemudian" yang dipakai git-bug adalah arah yang waras. Kalau riwayat bug disimpan dalam format terbuka di dalam git, keputusan untuk memakai layanan tambahan jadi keputusan yang bisa dibalik. Ini kebalikan dari kebiasaan umum, di mana data dilempar ke layanan pihak ketiga lebih dulu dan pertanyaan soal keluar dijawab belakangan.

Perbandingan singkat dengan cara lain

Ada tiga cara umum menyimpan issue, dan git-bug mengambil posisi yang berbeda dari ketiganya.

Cara pertama adalah layanan terpusat penuh, seperti GitHub Issues atau Jira. Keunggulannya jelas: tracker publik, integrasi luas, notifikasi, dan kolaborasi yang sudah dikenal semua orang. Harganya adalah ketergantungan, dan untuk data yang penting, ketergantungan itu bukan hal sepele.

Cara kedua adalah menyimpan issue di dalam repository sebagai file markdown biasa. Ini sederhana dan transparan, tapi cepat jadi tidak nyaman begitu jumlahnya banyak. Tidak ada query, tidak ada status yang terstruktur, dan setiap perubahan status berarti satu commit yang mengotori riwayat kode.

Cara ketiga adalah git-bug. Ia menyimpan datanya di dalam git seperti cara kedua, tapi dengan model data yang terstruktur, query, status, label, komentar, dan identitas. Karena tidak ada file yang muncul di struktur proyek, riwayat kode tetap bersih. Dan karena punya bridge, ia bisa dipakai sebagai lapisan lokal di atas layanan terpusat yang sudah berjalan.

Yang perlu dicatat, git-bug bukan pengganti penuh layanan terpusat untuk proyek besar. Ia pengganti yang baik untuk bagian yang paling sering dipakai satu orang atau tim kecil: membuat, membaca, menyaring, dan menutup issue, semuanya tanpa keluar dari terminal dan tanpa bergantung pada koneksi.

Sumber

• Repository resmi git-bug, README dan dokumentasi: https://github.com/git-bug/git-bug
• Spesifikasi format on-disk git-bug: https://github.com/git-bug/git-bug/blob/master/doc/model.md
• Panduan instalasi: https://github.com/git-bug/git-bug/blob/master/INSTALLATION.md

Catatan: seluruh rincian fitur, perintah, dan status pengembangan dalam artikel ini bersumber dari dokumentasi resmi repository git-bug dan belum diverifikasi lewat pengujian independen. Angka bintang dan fork diambil dari halaman repository pada 26 September 2026 dan bisa berubah.

Rekomendasi Tools & Layanan

Kalau lo mau langsung praktikkan panduan di atas, dua layanan yang gue pake sehari-hari: free trial Alibaba Cloud buat coba-coba tanpa biaya di awal, dan ECS instance 9th-gen kalau udah siap naik ke VPS production.