Cher journal,

À l'occasion de la sortie de la version 0.4 de git-bug, je me suis dit que je pourrais te raconter un peu de quoi il en retourne.

git-bug est un bug tracker distribué intégré dans git, c'est-à-dire que l'ensemble des données des bugs est stocké sous forme d'objet git, sans polluer les branches et fichiers normaux. Mais pour quoi faire ? Et bien par rapport à un bug tracker classique, il y a plusieurs avantages :

Pas de dépendance à un service en particulier (par exemple si ton bugtracker préféré se fait racheter par tousse Microsoft tousse) ;

Pas besoin d'infrastructure particulière : si tu utilises déjà un remote git pour collaborer, tu as un bugtracker ;

pour collaborer, tu as un bugtracker ; Tu peux consulter et éditer les bugs hors-ligne, avec l'interface que tu préfères, sans latence.

Mais alors, comment on fait un bugtracker distribué ? Le plus gros problème c'est la gestion des conflits. Comment faire si Alice et Bob modifient le même bug et s'échangent les données ensuite ?

La solution choisie, plutôt que de stocker simplement l'état d'un bug, est de stocker chaque opération d'édition individuellement.

+-------------+ +-----------+ +-------------+ +--------+ * --->| ADD_COMMENT |--->| SET_TITLE |--->| ADD_COMMENT |-->| CREATE | +-------------+ +-----------+ +-------------+ +--------+

Quand une fusion doit avoir lieu, l'une des deux versions voit ses nouvelles opérations placées à la fin de la chaine, à la manière d'un rebase. On a donc la garantie d'avoir un état final cohérent puisque c'est git-bug qui dérive l'état final de la chaine d'opération. Mais que se passe-t-il si deux personnes supprime la même étiquette ? Elle sera simplement supprimée une fois et l'action des deux personnes sera visible dans l'historique.

Voilà à quoi pourrait ressembler une opération :

{ "type" : "SET_TITLE" , "author" : { "name" : "René Descartes" , "email" : "rene.descartes@example.com" }, "timestamp" : 1533640589 , "title" : "This title is better" }

Ces opérations sont ensuite sérialisées et stockées dans des blob git et reliées dans une chaine de commit. Chaque bug a sa propre chaine de commit, accessible via une référence git. À chaque fois que le bug est modifié, une nouvelle série d'opérations est ajoutée à la chaine et la référence est mise à jour.

refs/bugs/<bug-id> | | v +-----------+ +-----------+ "ops" +-----------+ | Commit |--->| Tree |---------+----------->| Blob | (OperationPack) +-----------+ +-----------+ | +-----------+ | | | | v | "root" +-----------+ +-----------+ +-----------+ +----------->| Blob | (OperationPack) | Commit |--->| Tree |-- ... | +-----------+ +-----------+ +-----------+ | | | | | "media" +-----------+ +-----------+ v +----------->| Tree |---+--->| Blob | bug.jpg +-----------+ +-----------+ +-----------+ | +-----------+ | Commit |--->| Tree |-- ... | +-----------+ +-----------+ | +-----------+ +--->| Blob | demo.mp4 +-----------+

Comme tout est stocké sous forme d'objet git, on peut pousser tout ça vers un remote et collaborer, comme si on s'échangeait du code source.

Une autre propriété intéressante de la méthode, c'est qu'on peut stocker et lier les médias (typiquement, une capture d'écran) à un bug et les diffuser de la même façon.

Alors, à quoi ça ressemble tout ça ? Et bien ça dépend des goûts. Si tu préfères la ligne de commande, le scripting ou intégrer ça dans ton Vim, c'est possible. Voilà un aperçu:

# Ajouter un nouveau bug git bug add # Liste les bugs ouverts, trié par dernière édition git bug ls "status:open sort:edit" # Affiche l'état du bug f3781aee git bug show f3 # Selectionne le bug f3781aee parce que je sais bien que tu es un peu flemmard git bug select f3 # Ajoute un nouveau commentaire git bug comment add # Pousse les modifications vers le remote par défaut git bug push

Pour un usage plus efficace, il y a aussi l'interface interactive en terminal :

Ou sinon, pour les amateurs de vrai pixels et de clic-clic, git-bug embarque une interface web, mais il faut avouer qu'il y a encore du boulot :





Techniquement, le binaire de git-bug lance un serveur web local qui sert les fichiers de l'application js/react qui ont été compilé et inclus dans ce même binaire. L'application web s'interface avec le binaire grâce à une API GraphQL. Le déploiement reste donc extrêmement simple avec un unique binaire à copier, sans configuration.

La nouvelle version 0.4 apporte une fonctionalité qui a été beaucoup demandée, un importeur incrémental pour Github ! Après avoir utilisé git bug bridge configure pour saisir ses identifiants, un token d'API est généré automatiquement et git-bug devient capable d'aspirer les issues en local dans son modèle de donnée.

Et le futur ? Une de mes priorités est d'implémenter un exporteur vers Github. Quand ça sera fait, il sera possible d'utiliser git-bug comme un Github déporté, qui fonctionne en local et offline.

Une autre idée qui me trotte dans la tête est d'avoir une véritable gestion d'identité en embarquant les données publiques dans des objets git, clé de chiffrement incluse. De cette façon, il devient possible de les distribuer facilement, avec les données des bugs, de signer ses éditions, les vérifier, et même pourquoi pas de vérifier les commits git normaux sans avoir à chercher et importer les clés GPG.

Mais tout ça, c'est quand même beaucoup pour, en gros, un seul bonhomme. Mais peut-être, mon cher journal, que je trouverai des âmes vaillantes pour m'accompagner dans cette aventure…