Êtes-vous un étudiant de l'EPFL à la recherche d'un projet de semestre?
Travaillez avec nous sur des projets en science des données et en visualisation, et déployez votre projet sous forme d'application sur Graph Search.
Concept
Branche (gestion de configuration)
Résumé
En gestion de configuration logicielle, une branche est une dérivation dans l'histoire de l'évolution des éléments de configuration. Une branche est une évolution d'un élément ayant pour origine une version précise, produisant une «branche de version». Une branche de version correspond à un axe d'évolution de versions. Elle est rattachée à une branche source et peut découler sur plusieurs sous-branches. La gestion de l'ensemble des branches et des versions d'un produit constitue le versionnage (versioning en anglais) et est l'objet de la gestion de configuration.
Versionnage
L'évolution des versions se fait de façon linéaire au sein d'une même branche ; c’est-à-dire que les versions se suivent chronologiquement. L'apport des branches offre la possibilité d'avoir des évolutions de versions en parallèle.
Par exemple, le logiciel « Toto » a subi plusieurs évolutions depuis sa première version. À partir de la version 2.1, ses concepteurs décident de publier une version et de continuer à ajouter des fonctionnalités jusqu'à atteindre la version 3.0, qui changera fondamentalement le logiciel. Peu de temps après que cette dernière version est sortie, ils sont amenés à devoir corriger des bugs dans la version 2.1 ; il est alors nécessaire de créer une nouvelle branche.
1.0 -- 1.1 -- 1.2 -- 1.3 -- 1.4 -- 2.0 -- 2.1 -- 2.2 -- 2.3 -- 3.0
\ -- 2.1.1 -- 2.1.2 -- 2.1.3 Par défaut, l'évolution d'un produit au travers de l'historique de ses versions est un phénomène linéaire : le développeur A apporte ses modifications sur le produit, B ajoute ses fonctionnalités, C corrige le code de A etc. On parle alors de Mainline. Cependant, au cours de l'évolution d'un logiciel, il se peut que cette MainLine doive à la fois suivre son cours, mais aussi répondre à une contrainte qui va amener le produit à suivre une évolution parallèle à la MainLine. On a besoin alors de créer une branche. L'origine de la contrainte peut être externe : un des clients veut une modification qui lui est spécifique ou interne : on a besoin de pouvoir continuer à développer la Mainline tout en permettant la correction de défauts sur une branche en cours de tests.
\ -- 2.1.1 -- 2.1.2 -- 2.1.3 Par défaut, l'évolution d'un produit au travers de l'historique de ses versions est un phénomène linéaire : le développeur A apporte ses modifications sur le produit, B ajoute ses fonctionnalités, C corrige le code de A etc. On parle alors de Mainline. Cependant, au cours de l'évolution d'un logiciel, il se peut que cette MainLine doive à la fois suivre son cours, mais aussi répondre à une contrainte qui va amener le produit à suivre une évolution parallèle à la MainLine. On a besoin alors de créer une branche. L'origine de la contrainte peut être externe : un des clients veut une modification qui lui est spécifique ou interne : on a besoin de pouvoir continuer à développer la Mainline tout en permettant la correction de défauts sur une branche en cours de tests.
Source officielle
À propos de ce résultat
Cette page est générée automatiquement et peut contenir des informations qui ne sont pas correctes, complètes, à jour ou pertinentes par rapport à votre recherche. Il en va de même pour toutes les autres pages de ce site. Veillez à vérifier les informations auprès des sources officielles de l'EPFL.