L’idée est de gérer les tickets d’un projet dans le dépôt git du projet. Ainsi, pas de séparation entre le projet et ses tickets, pas de dépendance à une plateforme où les tickets risquent de rester bloqués en cas de migration d’une plateforme à une autre.
Bien sûr, il y a des ponts (bridge) développés pour les plateformes les plus connues, dont GitLab.
On peut donc pull les tickets de GitLab dans son dépôt local, les modifier, puis les push sur GitLab (ne gère cependant pas les fichiers attachés).
Je ne sais pas si se passer complètement d’une forge logiciel apporte plus d’avantages que d’inconvénients, mais l’idée est séduisante, puisque c’est une centralisation d’un système de versionnage distribué (git) qui pose le problème des numéros de tickets qui couplent trop fortement les commits (distribués) avec une instance unique de forge (silo centralisé).
git-bug répond très bien à cela.
Pour gérer les pull request, git fournit nativement un outil (request-pull), c’est dans la section email de la page de référence : Git - Reference. Les échanges se font alors par email.
Mais on pourrait très bien envisager un équivalent de git-bug pour les pull requests avec conservation de l’historique des échanges dans le dépôt.
