git-bug, bir Git deposunu dağıtık ve çevrimdışı öncelikli bir hata takip aracına dönüştürüyor

Hatalar Git nesneleri olarak saklanıyor

Tamamen bir Git deposunun içinde yaşayan açık kaynaklı hata takip aracı git-bug, Hacker News ana sayfasına çıktı. Projenin merkezindeki fikir, issue takibini doğrudan sürüm kontrolünün içine katmak: her hata, yorum ve etiket depo verisi olarak saklanıyor; böylece takip aracı kodla birlikte seyahat ediyor, geliştiricilerin halihazırda kullandığı remote'lar üzerinden eşitleniyor ve hiç ağ bağlantısı olmadan da çalışmaya devam ediyor.

Projenin README'sine göre bir depoyu klonlamak, hata veritabanının eksiksiz bir kopyasını veriyor; çünkü takip aracının tüm durumu doğrudan Git'in içine yazılıyor. Çalışma ağacına hiçbir şey eklenmediği için projenin kaynak dosyaları dokunulmadan kalıyor. Her şey yerel olduğu için, hataları listelemek veya birini açmak milisaniye ölçeğinde bir işlem olarak tanımlanıyor.

Saklama katmanı ayrıca resmî olarak belirtilmiş. Ayrı bir spec belgesi diskteki biçimi — entity DAG biçimi, kimlikler ve hata entity'si — tanımlıyor; açık hedefi, başkalarının alternatif uygulamalar yazmasına veya git-bug verisini doğrudan okuyan araçlar geliştirmesine izin vermek.

Desteklenen üç iş akışı

Yerel iş akışı en saf biçim: ekipler hataları git bug push ve git bug pull ile alışveriş ediyor; commit'lerde kullanılan aynı push-pull modeli.

Köprü iş akışı, git-bug'ı mevcut bir takip aracının yerel ön yüzü olarak ele alıyor. git bug bridge pull çalıştırmak issue'ları — çevrimdışı dahil — yerelde çalışmak üzere indiriyor ve git bug bridge push düzenlemeleri upstream servisine geri gönderiyor.

Üçüncü iş akışı, dış kullanıcıların OAuth kimlik doğrulamasıyla issue açabileceği herkese açık bir web portalı; bu hâlâ geliştirme aşamasında. README, web arayüzünün bu görevi henğer kaldıramadığını açıkça belirtiyor ve bu yönde katkı çağrısında bulunuyor.

Bir CLI, bir terminal arayüzü ve bir web arayüzü

Komut satırı arayüzü tüm yaşam döngüsünü kapsıyor: kimlik oluşturma, tercih ettiğiniz editörle hata açma, listeleme ve filtreleme (örneğin git bug ls "status:open sort:edit"), metin içeriğine göre arama ile hataları görüntüleme, yorumlama, açma veya kapatma.

Etkileşimli bir terminal arayüzü olan git bug termui, hatalara göz atmak ve düzenlemek için kullanılabilir. git bug webui ile başlayan daha zengin bir web arayüzü ise gezinme, arama, filtreleme, yorumlama ve başlık, etiket ile durum düzenlemeyi destekliyor. Ayrıca bir kod tarayıcısı olarak da işlev görüyor; dosya ağacı, sözdizimi vurgulamalı dosyalar, commit geçmişi ve diff'ler sunuyor.

Web arayüzü aynı Go binary'sinin içinde geliyor ve yerel bir HTTP sunucusu tarafından sunuluyor; şeması yayınlanmış bir GraphQL API üzerinden backend ile iletişim kuruyor. Man sayfalarının yanı sıra Bash, Zsh, fish ve PowerShell için kabuk tamamlaması sağlanıyor.

Mevcut takip araçlarına köprüler

git-bug, GitHub, GitLab, Jira ve Launchpad'e içe ve dışa aktarım yapabiliyor. Bir özellik matrisi her köprünün neyi desteklediğini ayrıntılandırıyor; bir köprü, etkileşimli olarak ya da elle — ad, hedef, depo URL'si, kullanıcı adı ve token ile — yapılandırılabiliyor. Tipik komutlar arasında issue'ları içe aktaran git bug bridge pull, değişiklikleri dışa aktaran git bug bridge push ve bir köprüyü silen git bug bridge rm yer alıyor.

Proje GPLv3 veya sonrası ile lisanslanmış, telif hakkı Michael Muré'ye ait; logo ise Viktor Teplov tarafından CC BY 4.0 lisansıyla sunuluyor. Katkılar pull request olarak geliyor ve topluluk sohbeti bir Matrix odasında gerçekleşiyor.

Neden önemli

Issue takibi, çoğu yazılım projesinde hâlâ başkasının veritabanında yaşanan son parçalardan biri. Barındırılan bir takip aracı bir kesinti yaşadığında, fiyatlandırmasını değiştirdiğinde veya kapandığında, bir projenin karar geçmişi erişilmez hale gelebilir veya taşınması maliyetli olabilir. git-bug bu düzeni tersine çeviriyor: issue'lar yalnızca biraz daha fazla depo verisi; her klonda çoğaltılan, kodu zaten koruyan aynı push ve pull ile yedeklenen ve hiçbir bağlantı olmadan düzenlenebilen veriler.

Köprüler benimsemeyi kolaylaştırıyor; bir ekip, GitHub veya Jira'yı ana sistem olarak tutarken git-bug'ı yerel bir arayüz olarak deneyebiliyor. Eksik nokta ise tamamlanmamış herkese açık portal; bu, projeyi şimdilik anonim kullanıcıların rapor göndermesine dayanan projelerden çok bakımcılar ve katkıda bulunanlar için daha uygun kılıyor. Hata verilerinin bir satıcıya değil depoya ait olmasını isteyen herkes için bu tasarım, nadir ve somut bir alternatif.