Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Branches dans une stratégie Gitflow Une stratégie de branchement Gitflow comporte généralement les branches suivantes. ![\[Les branches et les environnements d'une stratégie de branchement Gitflow.\]](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-branching-strategy.png) ## branche de fonctionnalités `Feature`les branches sont des branches à court terme dans lesquelles vous développez des fonctionnalités. La `feature` branche est créée en partant de la `develop` branche. Les développeurs itèrent, valident et testent le code dans la `feature` branche. Lorsque la fonctionnalité est terminée, le développeur en fait la promotion. Il n'existe que deux voies de transfert à partir d'une branche de fonctionnalités : + Fusionner dans la `sandbox` branche + Créez une demande de fusion dans la `develop` succursale | | | | --- |--- | | Convention de dénomination : | `feature/__` | | Exemple de convention de dénomination : | `feature/123456_MS_Implement_Feature_A` | ## branche de bac à sable La `sandbox` branche est une branche non standard à court terme pour Gitflow. Cependant, il est utile pour le développement de CI/CD pipelines. La `sandbox` branche est principalement utilisée aux fins suivantes : + Effectuez un déploiement complet dans l'environnement sandbox en utilisant les CI/CD pipelines plutôt qu'un déploiement manuel. + Développez et testez un pipeline avant de soumettre des demandes de fusion pour des tests complets dans un environnement inférieur, tel que le développement ou les tests. `Sandbox`les branches sont de nature temporaire et ne sont pas destinées à durer longtemps. Ils doivent être supprimés une fois les tests spécifiques terminés. | | | | --- |--- | | Convention de dénomination : | `sandbox/__` | | Exemple de convention de dénomination : | `sandbox/123456_MS_Test_Pipeline_Deploy` | ## développer une branche La `develop` branche est une branche durable dans laquelle les fonctionnalités sont intégrées, créées, validées et déployées dans l'environnement de développement. Toutes les `feature` branches sont fusionnées dans la `develop` branche. Les fusions avec la `develop` branche sont effectuées par le biais d'une demande de fusion qui nécessite une compilation réussie et deux approbations de développeurs. Pour empêcher la suppression, activez la protection des branches sur la `develop` branche. | | | | --- |--- | | Convention de dénomination : | `develop` | ## branche de sortie Dans Gitflow, `release` les branches sont des branches à court terme. Ces branches sont spéciales car vous pouvez les déployer dans plusieurs environnements, en adoptant la méthodologie Build-Once, Deploy-Many. `Release`les branches peuvent cibler les environnements de test, de préparation ou de production. Une fois qu'une équipe de développement a décidé de promouvoir des fonctionnalités dans des environnements supérieurs, elle crée une nouvelle `release` branche et utilise le numéro de version incrémenté par rapport à la version précédente. Au niveau de chaque environnement, les déploiements nécessitent des approbations manuelles pour pouvoir être effectués. `Release`les branches doivent nécessiter la modification d'une demande de fusion. Une fois que la `release` branche a été déployée en production, elle doit être fusionnée à nouveau dans les `main` branches `develop` et pour s'assurer que les corrections de bogues ou les correctifs seront intégrés dans les futurs efforts de développement. | | | | --- |--- | | Convention de dénomination : | `release/v{major}.{minor}` | | Exemple de convention de dénomination : | `release/v1.0` | ## branche principale La `main` branche est une branche à longue durée de vie qui représente toujours le code en cours d'exécution en production. Le code est automatiquement fusionné dans la `main` branche à partir d'une branche de version après un déploiement réussi depuis le pipeline de publication. Pour empêcher la suppression, activez la protection des branches sur la `main` branche. | | | | --- |--- | | Convention de dénomination : | `main` | ## branche bugfix La `bugfix` branche est une branche à court terme qui est utilisée pour résoudre les problèmes dans les branches de publication qui n'ont pas été mises en production. Une `bugfix` branche ne doit être utilisée que pour promouvoir les corrections apportées dans `release` les branches aux environnements de test, de test ou de production. Une `bugfix` branche est toujours dérivée d'une `release` branche. Une fois le correctif testé, il peut être promu vers la `release` branche par le biais d'une demande de fusion. Vous pouvez ensuite faire avancer la `release` branche en suivant le processus de publication standard. | | | | --- |--- | | Convention de dénomination : | `bugfix/__` | | Exemple de convention de dénomination : | `bugfix/123456_MS_Fix_Problem_A` | ## branche hotfix La `hotfix` succursale est une succursale à court terme utilisée pour résoudre les problèmes de production. Il ne doit être utilisé que pour promouvoir des correctifs qui doivent être accélérés pour atteindre l'environnement de production. Une `hotfix` branche est toujours issue d'une branche. `main` Une fois le correctif testé, vous pouvez le promouvoir en production par le biais d'une demande de fusion dans la `release` branche à partir `main` de laquelle il a été créé. Pour les tests, vous pouvez ensuite faire avancer la `release` branche en suivant le processus de publication standard. | | | | --- |--- | | Convention de dénomination : | `hotfix/__` | | Exemple de convention de dénomination : | `hotfix/123456_MS_Fix_Problem_A` |