Simyl
simylflow
Accueil du cours
Module 3 : Tickets et traçabilité
Leçon 3 sur 4
10 min

Lier les commits, les PR et les tickets

Faire en sorte que le travail raconte une seule histoire.

1Identifiants de tickets dans les noms de branches et les commits

Un identifiant de ticket dans le nom de votre branche coûte trois secondes à taper et économise des heures de changement de contexte plus tard. La convention est simple :

feature/PROJ-123-add-password-reset
fix/PROJ-456-null-pointer-in-export
chore/PROJ-789-upgrade-node-20

L'identifiant du ticket (PROJ-123) est l'ancre. Le slug qui le suit (add-password-reset) est pour les humains qui lisent la sortie de git branch. Ensemble, ils créent une branche à la fois recherchable et lisible.

Le même principe s'applique aux commits. Inclure l'identifiant du ticket dans le message de commit — soit dans la ligne d'objet (fix(PROJ-456): handle null export payload) soit dans le corps — vous permet de retracer n'importe quelle ligne de code jusqu'à l'élément de travail qui l'a motivée. git log --grep="PROJ-456" retourne instantanément tous les commits liés à ce ticket, sur toutes les branches.

Cette traçabilité devient critique lors de la réponse aux incidents. Quand un déploiement casse, vous devez répondre rapidement à « qu'est-ce qui a changé ? ». Si les branches et les commits référencent des identifiants de tickets, le chemin de « ce commit a cassé la production » à « voici le ticket avec le contexte complet » prend quelques secondes. Sans ce lien, vous lisez des diffs et devinez l'intention.

2Descriptions de PR qui renvoient au ticket

La PR est l'endroit où le code rencontre le ticket. Une description de PR qui ne référence pas le ticket qu'elle implémente est une connexion manquée — le réviseur voit ce qui a changé mais pas pourquoi, et le ticket reste « en cours » jusqu'à ce que quelqu'un le déplace manuellement.

La plupart des plateformes prennent en charge la liaison par mots-clés qui automatise cela :

Closes #123
Fixes PROJ-456
Resolves #789

GitHub, GitLab et Bitbucket reconnaissent tous ces mots-clés dans les descriptions de PR et créeront automatiquement un lien (et fermeront optionnellement) le ticket référencé lorsque la PR fusionne. Linear et Jira prennent en charge une intégration similaire via les noms de branches ou les descriptions de PR. Le coût est d'une ligne dans votre modèle de PR. L'avantage est une traçabilité de bout en bout de la demande au déploiement.

Un bon modèle de description de PR est minimal :

  • Quoi : résumé en une phrase du changement.
  • Pourquoi : lien vers le ticket (qui contient le contexte complet).
  • Comment tester : si les critères d'acceptation ne sont pas évidents à partir du diff.

Les équipes qui lient systématiquement les PR aux tickets peuvent répondre à « qu'est-ce qui a été livré cette semaine ? » en interrogeant leur outil de suivi au lieu de lire git log. Le ticket devient la source unique de vérité pour un élément de travail — de la demande à l'implémentation jusqu'au déploiement.

3Fermeture automatique lors de la fusion

La fermeture automatique est le dernier maillon de la chaîne de traçabilité : lorsqu'une PR fusionne, le ticket référencé passe à « terminé » sans que personne ne touche à l'outil de suivi. Ça semble mineur. En pratique, cela élimine toute une catégorie de bruit de tickets périmés.

Sans fermeture automatique, les tickets persistent en « en cours » ou « en révision » longtemps après que le code a été livré. Le tableau semble incorrect. Les métriques de sprint sont inexactes. Les développeurs perdent du temps à déplacer manuellement les tickets vers la colonne terminée — ce qu'ils oublient de faire la moitié du temps, ce qui signifie que le tableau est toujours périmé.

La configuration dépend de votre stack. GitHub ferme automatiquement les tickets référencés avec Closes #123 dans la description de PR par défaut — aucune configuration nécessaire. Jira nécessite une intégration GitHub (ou Bitbucket ou GitLab) qui mappe les fusions de PR aux transitions de workflow. Linear le gère nativement lorsque les PR référencent des identifiants de tickets dans le nom de branche.

Le modèle est le même partout : référencez le ticket dans la PR, laissez l'outillage gérer le changement d'état. Une décision au moment de la création de la PR économise une étape manuelle à chaque fusion et garde votre tableau honnête.

Points clés
  • Un identifiant de ticket dans chaque branche et commit permet au vous-du-futur de retracer le pourquoi
  • Lier coûte peu cher ; le coût est une décision maintenant pour économiser cinq recherches plus tard
Pièges courants à éviter
  • Tickets qui se ferment sans PR liée
  • PR qui ne référencent aucun ticket