Présentation

git-bug est un système de suivi de bugs entièrement intégré à Git. Le projet compte plus de 10 k étoiles et 2 691 commits, ce qui montre une adoption notable dans la communauté open‑source. Il se définit comme « offline‑first », permettant de créer, modifier et consulter des tickets même sans connexion réseau, puis de synchroniser les changements via les mécanismes habituels de push et pull de Git.

Architecture et fonctionnement

Le cœur de git‑bug repose sur le modèle de données de Git : chaque bug est stocké sous forme d’objet Git, inscrit dans le DAG (Directed Acyclic Graph) du dépôt. Le format d’objet, décrit dans la spécification git‑bug, encode les identités, les états et les métadonnées du ticket. Parce que les tickets sont des objets Git, aucune donnée supplémentaire n’est ajoutée au répertoire de travail ; aucune nouvelle branche ou fichier n’apparaît dans le projet. Les opérations de création (« git bug add ») ou de mise à jour (« git bug comment », « git bug close ») se traduisent en commits qui se propagent comme tout autre changement de code.

La synchronisation s’appuie sur les commandes classiques git bug push et git bug pull. Ces commandes utilisent les mêmes protocoles que git push/git pull, ce qui garantit une latence de l’ordre de quelques millisecondes pour lister ou ouvrir un ticket, même sur des dépôts de grande taille. Le mode « bridge » ajoute une couche d’interopérabilité : des ponts vers GitHub, GitLab, Jira ou Launchpad traduisent les objets Git en tickets externes via une API GraphQL interne.

Intégration et flux de travail

git‑bug propose plusieurs interfaces : une CLI native, une UI terminal interactive (git bug termui) et une interface Web (WIP) servie par un serveur HTTP local. La CLI permet de créer une identité (git bug user create), d’ajouter un bug (git bug add) et de le pousser vers un remote (git bug push origin). La Web UI, empaquetée dans le même binaire Go, expose un schéma GraphQL qui alimente le client JavaScript. Cette architecture « single binary » simplifie le déploiement : un seul fichier exécutable suffit à la fois pour le terminal et le serveur Web.

git bug add
git bug push origin
git bug pull origin

Les bridges sont configurés via git bug bridge new ou en ligne de commande avec des paramètres explicites (--name, --target, --url, --token). Cette approche évite le verrouillage propriétaire : si un service tiers devient indisponible, les tickets restent accessibles dans le dépôt Git local.

Limites et perspectives

Le principal frein réside dans la maturité de la Web UI, qui reste en version « work in progress ». Sans serveur permanent, l’accès public aux tickets nécessite de déployer manuellement le serveur local, ce qui complique les scénarios de collaboration à grande échelle. De plus, la dépendance à Git implique que les équipes doivent maîtriser les concepts de branches, de conflits et de réécriture d’historique pour éviter des incohérences de tickets. Enfin, l’absence d’un système de notifications intégré limite la visibilité en temps réel, un point que les contributeurs devront adresser dans les futures versions.