Adopter une stratégie de branchement Git

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Les systèmes de gestion de versions distribués comme Git vous offrent une flexibilité dans votre manière d’utiliser la gestion de version pour partager et gérer du code. Votre équipe doit trouver un équilibre entre cette flexibilité et la nécessité de collaborer et de partager du code de manière cohérente.

Les membres de l’équipe publient, partagent, passent en revue et itèrent sur les modifications de code via des branches Git partagées avec d’autres. Adoptez une stratégie de création de branche pour votre équipe. Cela permet d'améliorer votre collaboration et consacrer moins de temps dans la gestion des versions et plus de temps dans le développement du code.

Les stratégies suivantes dans la création de branche sont basées sur notre manière d’utiliser Git ici chez Microsoft. Pour plus d’informations, consultez Comment nous utilisons Git chez Microsoft.

Simplifiez votre stratégie de branche

Simplifiez votre stratégie de branche. Créez votre stratégie à partir de ces trois concepts :

• Utilisez des branches de fonctionnalité pour toutes les nouvelles fonctionnalités et tous les correctifs de bogues.
• Fusionnez les branches de fonctionnalités dans la branche principale à l’aide de demandes de tirage.
• Conservez une branche principale de haute qualité et à jour.

Une stratégie qui développe ces concepts et évite toute contradiction permettra à votre équipe de disposer d'un flux de travail cohérent et facile à suivre en matière de gestion des versions.

Utilisez des branches de fonctionnalités pour votre travail

Développez vos fonctionnalités et corrigez les bogues dans les branches de fonctionnalités en fonction de votre branche principale. Ces branches sont également appelées branches de rubrique. Les branches de fonctionnalités isolent le travail en cours du travail terminé dans la branche principale. Les branches Git sont peu coûteuses à créer et à gérer. Les petits correctifs et modifications doivent également comporter leur propre branche de fonctionnalité.

La création de branches de fonctionnalités pour toutes vos modifications simplifie la révision de l’historique. Examinez les validations effectuées dans la branche ainsi que la requête de tirage qui a fusionné la branche.

Nommez vos branches de fonctionnalités par convention

Utilisez une convention d’affectation de noms cohérente pour vos branches de fonctionnalités afin d’identifier le travail effectué dans la branche. Vous pouvez également inclure d’autres informations dans le nom de la branche, telles que l'auteur de la branche.

Voici quelques suggestions pour nommer vos branches de fonctionnalités :

• users/username/description
• users/username/workitem
• bugfix/description
• feature/feature-name
• feature/feature-area/feature-name
• hotfix/description

Notes

Pour plus d’informations concernant la définition de stratégies permettant d’appliquer une stratégie de nommage de branche, consultez Exiger des dossiers de branche.

Utilisez des indicateurs de fonctionnalité pour gérer les branches de longue durée

En savoir plus concernant l’utilisation des indicateurs de fonctionnalité dans votre code.

Révisez et fusionnez le code avec des demandes de tirage

La révision qui a lieu dans une requête de tirage est essentielle pour améliorer la qualité du code. Fusionnez uniquement les branches par le biais de demandes de tirage approuvées par votre processus de révision. Évitez de fusionner des branches avec la branche principale sans requête de tirage.

Les révisions dans les demandes de tirage prennent du temps. Votre équipe doit se mettre d’accord sur ce qui est attendu des créateurs et des réviseurs de requêtes de tirage. Distribuez les responsabilités des réviseurs pour partager des idées au sein de votre équipe et répartir les connaissances de votre codebase.

Quelques suggestions pour les demandes de tirage réussies :

• Deux réviseurs sont un nombre optimal basé sur la recherche.
• Si votre équipe dispose déjà d’un processus de révision du code, intégrez les demandes de tirage dans ce que vous faites déjà.
• Veillez à affecter les mêmes réviseurs à un grand nombre de demandes de tirage. Les demandes de tirage fonctionnent mieux lorsque les responsabilités du réviseur sont partagées au sein de l’équipe.
• Fournissez suffisamment de détails dans la description permettant aux réviseurs d’être rapidement informés de vos modifications.
• Incluez une version build ou liée de vos modifications opérant dans un environnement indexé avec votre requête de tirage. D’autres peuvent facilement tester les modifications.

Conservez une branche principale de haute qualité et à jour

Le code de votre branche principale doit réussir les tests, se compiler correctement et rester à jour. Votre branche principale doit contenir ces qualités afin que les branches de fonctionnalités créées par votre équipe partent d’une version valide du code.

Configurez une stratégie de branche pour votre branche principale qui :

• Nécessite une requête de tirage pour fusionner le code. Cette approche empêche les envois directes vers la branche principale et garantit la discussion des modifications proposées.
• Ajoute automatiquement des réviseurs lorsqu’une requête de tirage est créée. Les membres de l’équipe ajoutés examinent le code et commentent les modifications apportées à la requête de tirage.
• Nécessite une génération réussie pour effectuer une requête de tirage. Le code fusionné dans la branche principale doit être généré correctement.

Conseil

Le pipeline de build pour vos demandes de tirage doit être rapide à exécuter, pour éviter toute interférence avec le processus de révision.

Gérer les mises en production

Utilisez des branches de mise en production pour coordonner et stabiliser les modifications dans une version de votre code. Cette branche est de longue durée et n’est pas fusionnée dans la branche principale d’une requête de tirage, contrairement aux branches de fonctionnalité. Créez autant de branches de mise en production que nécessaire. Souvenez-vous que chaque branche de mise en production active représente une autre version du code à prendre en charge. Verrouillez les branches de mise en production dès que vous êtes prêt à arrêter la prise en charge d’une version précise.

Utiliser des branches de version

Créez une branche de mise en production à partir de la branche principale lorsque vous êtes proche de votre mise en production ou d’un autre jalon, tel que la fin d’un sprint. Donnez à cette branche un nom clair l’associant à la version, par exemple release/20.

Créez des branches pour corriger les bogues de la branche de mise en production et fusionnez-les dans la branche de mise en production dans une demande de requête.

Porter les modifications vers la branche principale

Assurez-vous que les correctifs se placent à la fois dans votre branche de mise en production et dans votre branche principale. Une approche consiste à apporter des correctifs dans la branche de mise en production, puis apporter des modifications à votre branche principale pour empêcher la régression dans votre code. Une autre approche (et celle utilisée par l’équipe Azure DevOps) consiste à apporter constamment des modifications dans la ligne principale, puis à les transférer vers la branche de mise en production. Vous pouvez en savoir plus sur notre stratégie de flux de mise en production.

Dans cette rubrique, nous présenterons les modifications apportées à la branche de mise en production et leur transfert vers la ligne principale. Utilisez cherry-picking au lieu de la fusion pour un contrôle exact sur les validations renvoyées à la branche principale. La fusion de la branche de version dans la branche principale peut entraîner des modifications spécifiques à la version que vous ne souhaitez pas voir figurer dans la branche principale.

Mettez à jour la branche principale avec une modification apportée à la branche de mise en production en procédant de la manière suivante :

1. Créez un branche de fonctionnalité hors de la branche principale pour porter les modifications.
2. Cherry-pick les modifications de la branche de mise en production vers votre nouvelle branche de fonctionnalité.
3. Fusionnez la branche de fonctionnalité à la branche principale dans une deuxième requête de tirage.

Ce flux de travail de branche de mise en production conserve les piliers du workflow de base intacts : les branches de fonctionnalités, les demandes de tirage et une branche principale solde contenant toujours la dernière version du code.

Pourquoi ne pas utiliser des balises pour les mises en production ?

D’autres workflows de création de branches utilisent des balises Git pour marquer une validation spécifique comme mise en production. Les balises sont utiles pour marquer les points de votre historique comme importants. Les balises introduisent des étapes supplémentaires dans votre workflow, inutiles si vous employez des branches pour vos versions.

Les balises sont conservées et envoyées séparément de vos validations. Les membres de l’équipe peuvent facilement manquer le balisage d’une validation, les obligeant à revenir dans l’historique pour corriger la balise. Vous pouvez également oublier l’étape supplémentaire d’envoi de la balise, en laissant le développeur successif travailler à partir d’une version antérieure du code lors de la prise en charge de la version.

La stratégie de branche de mise en production élargit le workflow de branche de fonctionnalité de base pour gérer les mises en production. Votre équipe ne doit pas adopter un nouveau processus de gestion de version autre que le cherry-pick pour transférer les modifications.

Gérer les déploiements

Vous pouvez gérer plusieurs déploiements de votre code de la même manière que vous gérez plusieurs versions. Créez une convention de nommage claire, telle que deploy/performance-test, et traitez les branches d’environnement comme les branches de mise en production. Votre équipe doit convenir d’un processus de mise à jour des branches de déploiement avec le code de votre branche principale. Cherry-pick les corrections de bogues effectuées dans la branche de déploiement pour les transférer à la branche principale. Utilisez les mêmes étapes que pour le transfert des modifications à partir d’une branche de mise en production.

Cette suggestion ne s'applique pas si vous utilisez une forme de déploiement continu. Utilisez Azure Pipelines lors d’un déploiement continu pour promouvoir les builds de votre branche principale vers vos cibles de déploiement.