Faire en sorte que le travail raconte une seule histoire.
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.
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 :
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.
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.