Un système de tickets « localisé »

Ticgit se présente comme un système de tickets « localisé » (localized issue tracking). Contrairement aux plateformes de gestion de projets centralisées comme GitHub Issues, Jira ou GitLab, Ticgit ne nécessite aucun serveur dédié ni application web propriétaire. Il utilise le protocole Git pour synchroniser les tickets entre les contributeurs, de la même manière que le code source lui-même.

Selon la documentation officielle du projet, Ticgit stocke les tickets sous forme de métadonnées via la boîte à outils "/git-meta". Il s'agit donc d'une extension de Git, et non d'un système externe. L'absence de serveur permet d'éviter les interruptions de service, un avantage mis en avant par ses développeurs.

Installation et premières commandes

Ticgit est disponible pour les systèmes d'exploitation macOS, Linux et Windows sous forme d'un binaire d'environ 7 Mo. Deux méthodes d'installation sont proposées : un script shell à exécuter via la commande curl -fsSL https://ticgit.dev/install | sh, ou l'installation via le gestionnaire de paquets Rust Cargo avec cargo install ticgit. La version actuelle du logiciel, selon la page officielle, est la 0.3.1, sous licence MIT.

Une fois installé, l'utilisateur peut créer un ticket avec la commande ti new --title "fix oauth redirect" --tags bug. Le système génère alors un identifiant unique pour le ticket (par exemple a3f29c). Une liste des tickets est obtenue via ti list, qui affiche leur statut, leur priorité et leur étiquette (tag). Les tickets peuvent être fermés avec ti close suivi de l'identifiant ou d'un préfixe unique.

Fonctionnalités avancées : agents et synchronisation

Le projet introduit un mode « agent » : la commande ti agent permet à un script ou à un programme de prendre en charge un ticket. La documentation suggère un prompt typique : « run ti agent to learn ticgit, then find the next ticket, fix it and close it » (exécutez ti agent pour apprendre Ticgit, puis trouvez le ticket suivant, corrigez-le et fermez-le). Cette fonctionnalité ouvre la porte à une automatisation poussée du cycle de vie des tickets.

La synchronisation d'équipe est assurée par ti sync, qui récupère et pousse les tickets via les dépôts Git distants, en utilisant une référence spéciale (refs/meta/main). Selon les exemples fournis, cette commande peut importer des tickets entrants et exporter les modifications locales.

États des tickets et interface machine

Ticgit distingue plusieurs états pour les tickets :

  • Ouverts : new (nouveau), assigned (assigné), in-progress (en cours), blocked (bloqué), review (en révision)
  • Fermés : resolved (résolu), wontfix (ne sera pas corrigé), duplicate (doublon), invalid (invalide)

Le logiciel expose un schéma JSON stable (version 1) destiné aux agents et aux flux de travail automatisés. Les commandes ti show --json et ti list --json produisent respectivement un objet ticket unique ou un tableau de tickets. La documentation précise que les diagnostics d'erreur sont envoyés sur la sortie d'erreur standard (stderr), tandis que les sorties JSON normales sont émises sur stdout, sans codes d'échappement de couleur ANSI. Les échecs renvoient un code de sortie non nul.

Les identifiants des tickets peuvent être des UUID complets ou des préfixes uniques ; un préfixe ambigu ou manquant déclenche un diagnostic sur stderr et l'échec de la commande.

Implications pour les équipes de développement

Ticgit s'inscrit dans une tendance de décentralisation des outils de développement. En éliminant le besoin d'un serveur centralisé, il réduit la dépendance vis-à-vis des plateformes tierces et permet de travailler hors ligne ou dans des environnements isolés. La synchronisation par Git offre une traçabilité et un historique des tickets intégrés.

Cependant, cette approche impose une maîtrise de Git et une discipline d'équipe pour gérer les conflits potentiels lors de la synchronisation. De plus, l'absence d'interface web graphique native (au-delà de la ligne de commande) peut constituer un frein pour certaines équipes habituées aux interfaces riches des gestionnaires de tickets classiques.

Le projet, hébergé sur GitHub sous l'organisation de Scott Chacon (co-auteur du livre "Pro Git"), reste en version 0.3.1, ce qui suggère un développement encore jeune.