Git-bug: Distributed, offline-first bug tracker embedded in Git
Git-bug is a distributed, offline-first issue tracker that integrates directly with Git workflows and data storage without modifying project files.
summary is enough Skim the README for core features and architecture, then read the author's comment for the project's roadmap toward a local-first forge.
summary
Git-bug is an offline-first issue tracker that leverages Git's object model for distributed synchronization without adding tracking files to the source tree. It features terminal and web UIs, a GraphQL API, and bidirectional bridges to platforms like GitHub and Jira. Commenters debate whether issue tracking should be tightly coupled with code repositories, while discussing historical challenges of distributed trackers. The author's remarks further outline ambitious plans to expand the project into a complete local-first code forge.
key points
- Stores issue data and history inside Git references without cluttering the project directory with tracking files.
- Includes bidirectional bridges to import and export issues with external platforms like GitHub, GitLab, and Jira.
- Features a built-in terminal UI and a rich web UI powered by a local GraphQL backend.
who should read it
Developers looking for a self-hosted, offline-capable issue tracker that lives entirely within their Git repositories.
discussion warm
consensus
Commenters generally praise the project's design and potential for offline workflows, though many debate whether issue tracking should be decoupled from source code repositories.
pushback
Some users highlight historical challenges with distributed issue trackers, including identity management, SSH configuration constraints, and accessibility for non-technical contributors.
Hi, author here, nice to see some interest :-)
FYI, this is my near-term roadmap:
- have the webui accept external auth (like github oauth) so that it can be a public portal and accept external interactions - have the webui expose a git remote endpoint - slightly rework identities (and likely root them in did:plc for pubkey distribution, the identity system from bluesky, without being an ATProto thing), which would allow to share identities between repos way more naturally - extend to support pull-requests, possibly CI. That would make it a somewhat complete local-first forge that you can …
The project creator shares a near-term roadmap detailing plans to support external authentication, git remote endpoints, and pull requests to build a local-first forge.
Generated by an LLM from the article and thread. Check the sources before relying on it.