Branching Git pour les équipes Agile

La migration vers Git apporte une agilité sans précédent aux équipes de développement, voici pourquoi.

Sarah Goff-Dupont Sarah Goff-Dupont

Libérés du gel de code (code freeze) peu convivial et des méga-merges monolithiques qui affectent le contrôle de version centralisé, les développeurs peuvent facilement isoler le travail en cours et intégrer des couches verticales étroites. La création de branches et les merges sont si faciles avec Git que de nombreuses équipes créent de nouvelles branches pour chaque user story ou correctif de bug qu'elles implémentent. Ce modèle devient rapidement la nouvelle norme pour les équipes Agile, et pour cause !

Prenez du pop-corn et découvrez l'un de nos webinaires les plus populaires. Vous y apprendrez : 

  • comment un modèle de branche par ticket aide les équipes à fournir du code fonctionnel en continu ;
  • à quoi ressemble le workflow pour les développeurs ;
  • comment il s'intègre à vos pratiques d'intégration continue et de revue du code ;
  • les compromis à envisager lors de l'évaluation de ce modèle.

Regarder et apprendre

Questions réponses

Intéressant, non ? 

Maintenant, si vous êtes comme moi, vous vous retrouvez rarement dans la partie questions réponses d'un webinaire. C'est bon, vous pouvez l'admettre. J'ai donc retranscrit une poignée de questions pour que vous puissiez les parcourir et les lire à votre guise. 

Q : Comment gérez-vous les numéros de version dans toutes ces branches ? Comment différenciez-vous ces lignes de code ? 

R : Les équipes nomment généralement la branche en fonction de la version de livraison correspondante. Par exemple, quand les membres de l'équipe qui conçoit Stash ont eu terminé la version 2.9, ils ont créé une branche stable nommée « stash-2.9 ». À présent, quand ils voient cette branche dans leur dépôt, ils savent clairement à quoi elle correspond. Vous pouvez utiliser toute convention de dénomination qui convient à votre équipe : il vous suffit d'inclure le numéro de version quelque part.

Q : Dans vos exemples, une personne travaillait sur chaque branche. Quelles sont la structure de branche et la convention de dénomination appropriées quand deux personnes travaillent sur une story ?

R : Deux personnes peuvent travailler sur la même branche de ticket. Assurez-vous simplement de suivre l'étiquette de base des branches partagées (par exemple, ne pas rebaser) et, plus généralement, évitez toute opération sur votre copie locale de la branche qui risquerait de compliquer la vie de vos collègues. Vous pouvez aussi demander à chaque collaborateur de créer sa propre branche pour ce ticket, puis de les merger fréquemment. Vous pouvez utiliser la convention de dénomination suivante : <nom/initiales>-<clé ticket>-<description> (par exemple, sarah-DEV-1234-nom-entreprise-mal-orthographié-sur-page-accueil), ce qui correspond plus ou moins à ce que nous utilisons pour les branches sur lesquelles un seul développeur travaille.

Q : Comment gérez-vous les dépendances si vous ne mergez pas tous les changements dans une seule branche dès qu'ils sont apportés à une branche de développement ?

R : Si les éléments dépendants sont tous deux en cours de développement, les développeurs travaillant sur chaque partie du code mergent fréquemment leurs changements. Vous pouvez faire cela dans Git sans avoir à merger d'abord une branche vers une branche centralisée : vous et l'autre développeur pouvez merger vos branches directement. L'autre option consiste à utiliser la branche d'intégration partagée dont nous avons parlé plus tôt.

Q : Il y a quelque temps, Martin Fowler a plaidé contre la création de branche de fonctionnalité, affirmant que cela entravait le refactoring et que, bien que la branche de fonctionnalité soit active, vous effectuez un développement continu, pas une intégration continue.

R : Oui, je connais son article sur ce sujet. C'était il y a un certain temps, peut-être en 2008 ou en 2009. Je pense que nos opportunités de réaliser une intégration continue sur les branches de fonctionnalité ont beaucoup progressé depuis. En outre, comme je l'ai dit dans la partie « considérations » de ce webinaire, une approche de branche par ticket implique que vous ne fassiez pas de l'intégration continue pure. Vous faites du développement continu et des tests continus, mais pas de l'intégration continue. Toutefois, vous pouvez vous en rapprocher en incluant une branche d'intégration partagée dans votre schéma de création de branche.