Llevaba un tiempo con una manía instalada: para levantar un bug tracker en serio me pedían una cuenta nueva, un servicio web más, y mis datos de seguimiento guardados en el servidor de un tercero. Todo el ecosistema moderno de desarrollo empuja en esa dirección: el código vive en un remoto, pero los issues, los comentarios y el historial de decisiones viven en la plataforma de turno. Y cuando esa plataforma tiene una caída, te quedas con el código y sin el contexto.
El proyecto git-bug le da la vuelta a eso. Es un tracker de bugs completamente distribuido y offline-first, que vive dentro del repositorio git que ya tienes. No agrega archivos a tu proyecto: guarda cada bug como un objeto git más, en refs separadas. Colaboras con git bug push y git bug pull, usando el remoto de siempre. Sin cuenta nueva, sin servicio externo.
Cómo funciona
Cada bug es una estructura de datos en forma de grafo acíclico dirigido (DAG), similar a cómo git maneja commits. Comentarios, ediciones, cambios de estado: todo es un nodo firmado criptográficamente que se agrega al grafo, y git se encarga de replicarlo cuando haces push o pull. El proyecto incluso publicó una especificación formal del formato en disco, con la idea de que cualquiera pueda implementar herramientas compatibles. Escrito en Go, GPLv3, con más de 10.000 estrellas en GitHub y desarrollo activo a la fecha.
Viene con tres interfaces: CLI directo, una terminal interactiva (git bug termui) y una web UI que corre desde el mismo binario de Go y se sirve por HTTP local, hablando con el backend por GraphQL. También incluye un navegador de código, con árbol de archivos y diffs, que en la práctica lo convierte en una vista local de todo el repo.
Bridges: la parte inteligente
El detalle que más me gusta son los bridges. git-bug puede importar y exportar bugs desde y hacia GitHub, GitLab, Jira y Launchpad. Esto lo convierte en una copia local y offline de un tracker que no controlas. Si el servicio externo se cae o cambia de opinión sobre su API, tú sigues con tus datos completos en tu repo. Es lo contrario del vendor lock-in: la plataforma se transforma en un espejo, no en la fuente de verdad.
Mi opinión
Me parece una idea que debió existir hace años. Quien administra infraestructura en servidores propios valora cualquier herramienta que no me pida otra cuenta ni otro servicio que mantener. git-bug corre local, no manda tus datos a ninguna parte, y sobrevive a caídas de terceros porque todo el estado vive en el mismo repo que ya respaldas. Para proyectos open source con issues públicos, todavía le falta madurez en la web UI como portal externo (está marcado como WIP en el README). Pero para equipos pequeños, proyectos personales o cualquier entorno donde no quieres depender de una plataforma para saber qué está roto, es una solución muy limpia.
Lo probé en un repo propio, no en producción, y funcionó bien en las operaciones básicas. Mi conclusión: no va a reemplazar a GitHub Issues para nada masivo, pero como tracker personal embebido en git cumple exacto lo que promete.
Fuente del tema: git-bug: Distributed, offline-first bug tracker integrated in Git, del repo oficial del proyecto.
Fuente de inspiración: git-bug: Distributed, offline-first bug tracker integrated in Git
