Une branche par ticket : sachez toujours où se trouve le code
Un bug réapparaît et plus personne ne sait dans quelle branche se trouvait le correctif. Un client demande si sa demande est déjà en ligne, et vous cherchez dix minutes dans Git. Quelques règles fixes sur les branches et les commits suffisent pour en finir. Voici comment les mettre en place.
1.Un ticket, une branche
Commencez chaque tâche à partir d’un ticket. Si le travail est trop gros pour une branche, c’est que le ticket est trop gros : découpez-le en sous-tâches ayant chacune leur numéro. Une pull request reste ainsi assez petite pour une bonne relecture.
2.Le numéro de ticket dans le nom de branche
Convenez d’un format fixe, par exemple feature/ASUP-12-courte-description ou fix/ASUP-14-ideal-callback. Le préfixe indique le type de travail, le numéro le ticket concerné. Les outils qui reconnaissent le numéro peuvent alors lier la branche automatiquement.
3.Le numéro dans chaque commit
Placez le numéro de ticket au début de votre message de commit : ASUP-12 valider le formulaire de connexion. Même si un commit atterrit plus tard dans une autre branche, vous voyez à quel ticket il appartient. Avec les smart commits, vous mettez le ticket à jour en même temps, par exemple avec #time 45m ou #review.
4.Les pull requests mettent le ticket à jour
Faites passer le ticket en In Review à l’ouverture d’une pull request, et la branche en fusionnée lors du merge. Le statut sur le tableau est alors juste sans que personne n’ait à y penser.
5.Vérifiez-le lors de la relecture
Inscrivez dans vos règles de relecture que le numéro de ticket figure dans la branche et dans les commits. Une pull request sans ticket est renvoyée. Au bout de quelques semaines, tout le monde le fait naturellement.
En résumé
- Un ticket, une branche
- Le numéro de ticket dans le nom de branche
- Le numéro dans chaque commit
- Les pull requests mettent le ticket à jour
- Vérifiez-le lors de la relecture