git-bug turns a Git repository into a distributed, offline-first bug tracker

Bugs stored as Git objects

git-bug, an open-source bug tracker that lives entirely inside a Git repository, has landed on the Hacker News front page. The project's central idea is to fold issue tracking into version control itself: every bug, comment and label is stored as repository data, so the tracker travels with the code, syncs over the remotes developers already use, and keeps working with no network at all.

According to the project's README, cloning a repository gives you a complete copy of its bug database, since all tracker state is written into Git itself. Nothing is added to the working tree, so the project's source files remain untouched. Because everything is local, listing bugs or opening one is described as a millisecond-scale operation.

The storage layer is also formally specified. A separate spec document defines the on-disk format — the entity DAG format, identities and the bug entity — with the explicit goal of letting other people write alternative implementations or build tools that read git-bug data directly.

Three supported workflows

The native workflow is the purest form: teams exchange bugs with git bug push and git bug pull, the same push-and-pull model used for commits.

The bridge workflow treats git-bug as a local front end for an existing tracker. Running git bug bridge pull downloads issues to work on locally — including offline — and git bug bridge push sends edits back to the upstream service.

The third workflow, a public web portal where outside users could file issues through OAuth authentication, is still work in progress. The README states plainly that the web UI is not yet up to that task and invites contributions toward it.

A CLI, a terminal UI and a web UI

The command-line interface covers the full lifecycle: creating an identity, filing a bug through your preferred editor, listing and filtering (for example git bug ls "status:open sort:edit"), searching by text content, and showing, commenting on, opening or closing bugs.

An interactive terminal interface, git bug termui, is available for browsing and editing bugs. A richer web interface launches with git bug webui and supports browsing, searching, filtering, commenting, and editing titles, labels and status. It also doubles as a code browser, offering a file tree, syntax-highlighted files, commit history and diffs.

The web UI ships inside the same Go binary and is served by a local HTTP server, communicating with the backend through a GraphQL API whose schema is published. Shell completion is provided for Bash, Zsh, fish and PowerShell, alongside man pages.

Bridges to existing trackers

git-bug can import from and export to GitHub, GitLab, Jira and Launchpad. A feature matrix spells out what each bridge supports, and a bridge can be configured interactively or manually with a name, target, repository URL, login and token. Typical commands include git bug bridge pull to import issues, git bug bridge push to export modifications and git bug bridge rm to delete a bridge.

The project is released under the GPLv3 or later, copyright Michael Muré, with the logo by Viktor Teplov under a CC BY 4.0 licence. Contributions come in as pull requests, and the community chat happens in a Matrix room.

Why it matters

Issue tracking is one of the last pieces of most software projects that still lives in someone else's database. When a hosted tracker suffers an outage, changes its pricing or shuts down, the history of a project's decisions can become hard to reach or costly to migrate. git-bug inverts that arrangement: issues are simply more repository data, replicated in every clone, backed up by the same push and pull that already protect the code, and editable with no connectivity at all.

The bridges soften adoption, since a team can keep GitHub or Jira as the system of record while trying git-bug as a local interface. The gap is the unfinished public-facing portal, which for now makes it a better fit for maintainers and contributors than for projects that rely on anonymous users filing reports. For anyone who wants their bug data to belong to the repository rather than a vendor, the design is a rare and concrete alternative.