Adopter une stratégie de branchement Git
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018
Les systèmes de contrôle de version distribués tels que Git vous offrent une flexibilité dans la façon dont vous utilisez le contrôle 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érer sur les modifications de code via des branches Git partagées avec d’autres personnes. Adoptez une stratégie de branchement pour votre équipe. Vous pouvez collaborer mieux et passer moins de temps à gérer le contrôle de version et à développer du code.
Les stratégies de branchement suivantes sont basées sur la façon dont nous utilisons Git ici chez Microsoft. Pour plus d’informations, consultez La façon dont nous utilisons Git chez Microsoft.
Gardez votre stratégie de branche simple
Gardez votre stratégie de branche simple. 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.
- Fusionner des branches de fonctionnalités dans la branche principale à l’aide de requêtes de tirage.
- Conservez une branche principale de haute qualité et à jour.
Une stratégie qui étend ces concepts et évite les contradictions entraîne un flux de travail de contrôle de version pour votre équipe qui est cohérent et facile à suivre.
Utiliser 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 caractéristiques isolent le travail en cours à partir du travail terminé dans la branche principale. Les branches Git sont peu coûteuses pour créer et gérer. Même les petits correctifs et les modifications doivent avoir leur propre branche de fonctionnalité.
La création de branches de fonctionnalités pour toutes vos modifications facilite l’examen de l’historique. Examinez les validations effectuées dans la branche et examinez la demande 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 pour identifier le travail effectué dans la branche. Vous pouvez également inclure d’autres informations dans le nom de la branche, telles que celles qui ont créé la branche.
Quelques suggestions pour nommer vos branches de fonctionnalités :
- utilisateurs/nom d’utilisateur/description
- utilisateurs/nom d’utilisateur/workitem
- correction/description de bogues
- feature/feature-name
- feature/feature-area/feature-name
- correctif logiciel/description
Notes
Pour plus d’informations sur la définition de stratégies pour appliquer une stratégie d’affectation de noms de branche, consultez Exiger des dossiers de branche.
Utiliser des indicateurs de fonctionnalité pour gérer les branches de longue durée
Mer informasjon sur l’utilisation d’indicateurs de fonctionnalité dans votre code.
Passer en revue et fusionner du code avec des demandes d’extraction
La révision qui a lieu dans une demande de tirage est essentielle pour améliorer la qualité du code. Fusionnez uniquement les branches par le biais de demandes de tirage qui passent votre processus de révision. Évitez de fusionner des branches vers la branche principale sans demande de tirage.
Les révisions dans les demandes de tirage prennent du temps. Votre équipe doit s’entendre sur ce qui est attendu des créateurs et réviseurs de demande de tirage. Distribuez les responsabilités des réviseurs pour partager des idées au sein de votre équipe et diffuser les connaissances de votre codebase.
Quelques suggestions pour les demandes de tirage réussies :
- Deux réviseurs sont un nombre optimal en fonction de la recherche.
- Si votre équipe dispose déjà d’un processus de révision de code, apportez des 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 des réviseurs sont partagées au sein de l’équipe.
- Fournissez suffisamment de détails dans la description pour accélérer rapidement les révisions avec vos modifications.
- Incluez une version de build ou liée de vos modifications s’exécutant dans un environnement intermédiaire avec votre demande de tirage. D’autres peuvent facilement tester les modifications.
Conserver une branche principale de haute qualité et à jour
Le code de votre branche principale doit passer des tests, générer correctement et toujours être actif. Votre branche principale a besoin de ces qualités afin que les branches de fonctionnalités créées par votre équipe commencent par une bonne version connue du code.
Configurez une stratégie de branche pour votre branche principale qui :
- Nécessite une demande de tirage pour fusionner du code. Cette approche empêche les envois directs vers la branche principale et garantit la discussion des modifications proposées.
- Ajoute automatiquement des réviseurs lorsqu’une demande de tirage est créée. Les membres de l’équipe ajoutés passent en revue le code et commentent les modifications apportées à la demande de tirage.
- Nécessite une build réussie pour terminer une demande de tirage. Le code fusionné dans la branche principale doit être généré correctement.
Conseil
Le pipeline de build de vos demandes de tirage doit être rapide à terminer. Il n’interfère donc pas avec le processus d’examen.
Gérer les versions
Utilisez les branches de mise en production pour coordonner et stabiliser les modifications dans une version de votre code. Cette branche est longue et n’est pas fusionnée dans la branche principale dans une demande de tirage, contrairement aux branches de fonctionnalité. Créez autant de branches de mise en production que nécessaire. N’oubliez pas que chaque branche de mise en production active représente une autre version du code que vous devez prendre en charge. Verrouiller les branches de mise en production lorsque vous êtes prêt à arrêter de prendre en charge une version particulière.
Utiliser des branches de version
Créez une branche de mise en production à partir de la branche principale lorsque vous vous rapprochez de votre version ou d’un autre jalon, tel que la fin d’un sprint. Donnez à cette branche un nom clair qui l’associe à la version, par exemple release/20.
Créez des branches pour corriger les bogues de la branche de mise en production et les fusionner dans la branche de mise en production dans une demande de tirage.
Le port revient à la branche principale
Assurez-vous que les correctifs sont présents 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 dans 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 à toujours apporter des modifications dans la ligne principale, puis à les porter vers la branche de mise en production. Vous pouvez en savoir plus sur notre stratégie de flux de publication .
Dans cette rubrique, nous allons aborder les modifications apportées à la branche de mise en production et les porter dans la ligne principale. Utilisez la sélection de cerises au lieu de fusionner afin que vous disposiez d’un contrôle exact sur les validations qui sont transférées vers la branche principale. La fusion de la branche de fonctionnalité dans la branche principale peut apporter des modifications spécifiques aux versions que vous ne souhaitez pas dans la branche principale.
Mettez à jour la branche principale avec une modification apportée dans la branche de mise en production en procédant comme suit :
- Créez une branche de fonctionnalité hors de la branche principale pour porter les modifications.
- Cherry-pick the changes from the release branch to your new feature branch.
- Fusionnez la branche de fonctionnalité dans la branche principale dans une deuxième demande de tirage.
Ce flux de travail de branche de mise en production conserve les piliers du flux de travail de base intact : branches de fonctionnalités, requêtes de tirage et branche principale forte qui possède toujours la dernière version du code.
Pourquoi n’utilisez-vous pas des balises pour les versions ?
D’autres flux de travail de branchement utilisent des balises Git pour marquer une validation spécifique en tant que version. Les balises sont utiles pour marquer des points dans votre historique comme étant importantes. Les balises introduisent des étapes supplémentaires dans votre flux de travail qui ne sont pas nécessaires si vous utilisez 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 de marquer une validation, puis revenir dans l’historique après pour corriger la balise. Vous pouvez également oublier l’étape supplémentaire pour envoyer la balise, en laissant le développeur suivant 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 étend le flux de travail de branche de fonctionnalité de base pour gérer les versions. Votre équipe n’a pas besoin d’adopter un nouveau processus de contrôle de version autre que le choix de cerise pour les modifications de port.
Gérer les déploiements
Vous pouvez gérer plusieurs déploiements de votre code de la même façon que vous gérez plusieurs versions. Créez une convention d’affectation de noms claire, telle que le déploiement/le test des performances, et traitez les branches d’environnement comme les branches de mise en production. Votre équipe doit accepter un processus de mise à jour des branches de déploiement avec le code de votre branche principale. Corrections de bogues cherry-pick dans la branche de déploiement vers la branche principale. Utilisez les mêmes étapes que le portage des modifications à partir d’une branche de mise en production.
Une exception à cette recommandation est si vous utilisez une forme de déploiement continu. Utilisez Azure Pipelines lors de l’utilisation d’un déploiement continu pour promouvoir les builds de votre branche principale vers vos cibles de déploiement.