J'ai vu ces mots beaucoup de fois dans les discussions sur Subversion (et je suppose les référentiels généraux).
J'ai utilisé SVN pour mes projets depuis quelques années, mais je n'ai jamais saisi le concept complet de ces répertoires.
Que veulent-ils dire ?
Hmm, je ne suis pas sûr d'être d'accord avec Nick sur le fait que le tag est similaire à une branche. Une balise est juste un marqueur
Tronçon constituerait le corps principal du développement, depuis le début du projet jusqu'à aujourd'hui.
Branche sera une copie du code dérivé d'un certain point du tronc qui est utilisé pour appliquer des changements majeurs au code tout en préservant l'intégrité du code dans le tronc. Si les changements majeurs fonctionnent comme prévu, ils sont généralement réintégrés dans le tronc.
Étiquette Il y aura un moment dans le temps sur le tronc ou une branche que vous souhaitez préserver. Les deux principales raisons de la préservation sont qu'il s'agit d'une version majeure du logiciel, qu'il s'agisse d'une version alpha, bêta, RC ou RTM, ou qu'il s'agit du point le plus stable du logiciel avant que les révisions majeures du tronc ne soient appliquées.
Dans les projets open source, les branches majeures qui ne sont pas acceptées dans le tronc par les parties prenantes du projet peuvent devenir les bases pour fourches -- par exemple, des projets totalement séparés qui partagent une origine commune avec d'autres codes sources.
Les sous-arbres des branches et des étiquettes se distinguent du tronc de la manière suivante :
Subversion permet aux administrateurs de systèmes de créer crochet scripts qui sont déclenchés pour être exécutés lorsque certains événements se produisent ; par exemple, la validation d'un changement dans le référentiel. Il est très commun pour une implémentation typique de référentiel Subversion de traiter tout chemin contenant "/tag/" pour être protégé en écriture après la création ; le résultat net est que les tags, une fois créés, sont immuables (au moins pour les utilisateurs "ordinaires"). Ceci est fait via le hook scripts, qui renforce l'immuabilité en empêchant d'autres changements si étiquette est un nœud parent de l'objet modifié.
Subversion a également ajouté des fonctionnalités, depuis la version 1.5, relatives au "suivi de la fusion des branches", de sorte que les modifications apportées à une branche peuvent être fusionnés dans le tronc avec le support de la fusion incrémentale et "intelligente".
La confusion avec les tags et les branches est que dans svn il n'y a pas vraiment de distinction entre eux, à part le nom du répertoire. Dans svn, vous êtes en mesure de livrer des modifications à une balise, et en fait, il est difficile d'empêcher cela. La plupart des autres VCS traitent les tags comme des instantanés immuables (points dans le temps).
Tags est également souvent utilisé pour les tests et la vérification des jalons par l'utilisateur régulier. Ce serait un bon endroit pour mettre un prototype aussi (juste quelques idées sur le dessus de ma tête).
@KenLiu Il existe des crochets qui permettent de rendre les balises immuables. En d'autres termes, vous pouvez créer et vérifier une balise, mais sans y apporter de modifications. Bien sûr, une balise faisant partie du référentiel signifie que l'historique complet est disponible. Si quelqu'un modifie une balise, vous pouvez le suivre et savoir pourquoi. Dans de nombreux VCS, si vous modifiez une balise, il peut n'y avoir aucun moyen de le savoir.
Tout d'abord, comme @AndrewFinnell et @KenLiu le soulignent, dans SVN les noms de répertoires eux-mêmes ne signifient rien -- "trunk, branches et tags" sont simplement une convention commune qui est utilisée par la plupart des dépôts. Tous les projets n'utilisent pas tous les répertoires (il est assez courant de ne pas utiliser du tout les "tags"), et en fait, rien ne vous empêche de les appeler comme vous le souhaitez, bien que briser la convention soit souvent source de confusion.
Je vais décrire le scénario d'utilisation le plus courant des branches et des balises, et donner un exemple de leur utilisation.
Tronçon : La zone de développement principale. C'est l'endroit où se trouve la prochaine version majeure du code, et où se trouvent généralement toutes les nouvelles fonctionnalités.
Branches : Chaque fois que vous publiez une version majeure, une branche est créée. Cela vous permet de corriger des bogues et de faire une nouvelle version sans avoir à publier les dernières fonctionnalités - éventuellement inachevées ou non testées.
Tags : Chaque fois que vous diffusez une version (version finale, candidats à la diffusion (RC) et bêtas), vous créez une étiquette pour celle-ci. Cela vous donne une copie ponctuelle du code tel qu'il était à ce moment-là, ce qui vous permet de revenir en arrière et de reproduire les bogues si nécessaire dans une version antérieure, ou de rééditer une version antérieure exactement comme elle était. Les branches et les balises dans SVN sont légères - sur le serveur, il n'y a pas de copie complète des fichiers, juste un marqueur disant "ces fichiers ont été copiés à cette révision" qui ne prend que quelques octets. En gardant cela à l'esprit, vous ne devriez jamais vous soucier de créer une balise pour tout code publié. Comme je l'ai dit précédemment, les balises sont souvent omises et à la place, un changelog ou un autre document clarifie le numéro de révision lorsqu'une version est publiée.
Par exemple, disons que vous démarrez un nouveau projet. Vous commencez à travailler dans "trunk", sur ce qui sera finalement publié comme version 1.0.
Une fois la version 1.0.0 terminée, vous branchez le tronc dans une nouvelle branche "1.0" et créez une étiquette "1.0.0". Maintenant, le travail sur ce qui sera éventuellement la 1.1 continue dans le tronc.
Vous rencontrez des bogues dans le code, vous les corrigez dans le tronc, puis vous fusionnez les corrections vers la branche 1.0. Vous pouvez aussi faire l'inverse, et corriger les bogues dans la branche 1.0 puis les fusionner à nouveau dans le tronc, mais généralement les projets s'en tiennent à la fusion dans un seul sens pour réduire le risque de manquer quelque chose. Parfois, un bogue ne peut être corrigé qu'en 1.0 parce qu'il est obsolète en 1.1. Cela n'a pas vraiment d'importance : vous voulez seulement vous assurer que vous ne sortez pas la version 1.1 avec les mêmes bogues que ceux qui ont été corrigés en 1.0.
Une fois que vous avez trouvé suffisamment de bogues (ou peut-être un bogue critique), vous décidez de faire une version 1.0.1. Vous créez donc une étiquette "1.0.1" à partir de la branche 1.0, et vous publiez le code. À ce stade, le tronc contient ce qui sera la 1.1, et la branche "1.0" contient le code 1.0.1. La prochaine fois que vous publierez une mise à jour de la 1.0, ce sera la 1.0.2.
Finalement, vous êtes presque prêt à sortir la version 1.1, mais vous voulez d'abord faire une bêta. Dans ce cas, vous créez probablement une branche "1.1" et une balise "1.1beta1". Maintenant, le travail sur ce qui sera la 1.2 (ou 2.0 peut-être) continue dans le tronc, mais le travail sur la 1.1 continue dans la branche "1.1".
Une fois que vous avez publié la version finale 1.1, vous faites un tag "1.1" à partir de la branche "1.1".
Vous pouvez également continuer à maintenir la version 1.0 si vous le souhaitez, en portant les corrections de bogues entre les trois branches (1.0, 1.1 et trunk). Ce qu'il faut retenir, c'est que pour chaque version principale du logiciel que vous maintenez, vous avez une branche qui contient la dernière version du code de cette version.
Une autre utilisation des branches est celle des caractéristiques. Il s'agit de brancher trunk (ou une de vos branches de version) et de travailler sur une nouvelle fonctionnalité de manière isolée. Une fois la fonctionnalité terminée, vous la réintégrez et supprimez la branche.
L'idée est la suivante : lorsque vous travaillez sur quelque chose de perturbateur (qui retarderait ou empêcherait d'autres personnes de faire leur travail), quelque chose d'expérimental (qui pourrait ne même pas être intégré), ou simplement quelque chose qui prend beaucoup de temps (et vous avez peur que cela retarde la sortie de la version 1.2 lorsque vous êtes prêt à brancher la 1.2 à partir du tronc), vous pouvez le faire de manière isolée dans la branche. Généralement, vous la maintenez à jour avec le tronc en fusionnant les changements en permanence, ce qui facilite la réintégration (fusion vers le tronc) lorsque vous avez terminé.
Notez également que le schéma de versionnement que j'ai utilisé ici n'est qu'un parmi d'autres. Certaines équipes font des versions de correction de bogues/maintenance en tant que 1.1, 1.2, etc., et des changements majeurs en tant que 1.x, 2.x, etc. L'usage ici est le même, mais vous pouvez nommer la branche "1" ou "1.x" au lieu de "1.0" ou "1.0.x". (A propos, versionnement sémantique est un bon guide sur la façon de faire des numéros de version).
Il n'est pas vrai que dans SVN les balises sont légères. Dans SVN, les tags sont une exportation complète du code, et perdent toute référence à l'endroit de l'arbre source d'où ils proviennent.
@baruch - C'est complètement faux. Les étiquettes sont légères et sont (en ce qui concerne Subversion lui-même) identiques aux branches.
En plus de ce que Nick a dit, vous pouvez trouver plus d'informations à l'adresse suivante Lignes en continu : Modèles de branchement pour le développement de logiciels parallèles
Dans cette figure main est le tronc, rel1-maint est une branche et 1.0 est une balise.
@Wolf il pourrait l'être - ce diagramme est assez générique quel que soit l'outil. Tous les SCMs utilisent des mots différents mais les mêmes concepts, il n'y a pas de différence entre trunk et Main ; ou trunk et master. Ce diagramme montre comment mon entreprise actuelle utilise SVN.
@gbjbaanb Merci de partager. ...et tags ne semblent pas être abordés par la question. Est-ce une pure coïncidence (également dans votre entreprise actuelle) qu'aucune fusion ne soit effectuée entre les branches principales et les branches gérées ?
@Wolf Pas de coïncidence - seulement une branche du tronc, faire le travail, fusionner à nouveau sur le tronc. Puis se brancher du tronc vers une branche de balises. Nous envisageons un autre "tronc" appelé Intégration dans lequel des branches terminées sont fusionnées pour des tests qui ne constituent pas une version, le tronc est toujours utilisé pour les branches que nous décidons de mettre dans la prochaine version. La seule fois où l'on fusionne du tronc vers une branche est pour mettre à jour une branche en cours depuis longtemps, mais il est préférable (et plus facile) de créer simplement une nouvelle branche à partir du tronc et d'y fusionner les modifications de votre ancienne branche si vous en avez besoin.
En général (vue agnostique des outils), une branche est le mécanisme utilisé pour le développement parallèle. Un SCM peut avoir de 0 à n branches. Subversion en a 0.
Tronçon est une branche principale recommandé par Subversion mais vous n'êtes en aucun cas obligé de le créer. Vous pouvez l'appeler "principal" ou "communiqués", ou ne pas en avoir du tout !
Branche représente un effort de développement. Il ne doit jamais être nommé d'après une ressource (comme 'vonc_branch') mais d'après :
Étiquette est un instantané des fichiers afin de pouvoir facilement revenir à cet état. Le problème est que le tag et la branche sont les mêmes dans Subversion. . Et je recommanderais certainement l'approche paranoïaque :
vous pouvez utiliser l'un des scripts de contrôle d'accès fournis avec Subversion pour empêcher quiconque de faire autre chose que de créer de nouvelles copies dans la zone des balises.
Une étiquette est définitive. Son contenu ne doit jamais changer. JAMAIS. Jamais. Vous avez oublié une ligne dans la note de mise à jour ? Créez une nouvelle balise. Rendez obsolète ou supprimez l'ancienne.
Maintenant, j'ai lu beaucoup de choses à propos de "fusionner à nouveau telle et telle branche dans telle et telle branche, puis finalement dans la branche du tronc". Cela s'appelle flux de fusion et il y a rien d'obligatoire ici . Ce n'est pas parce que vous avez une branche de tronc que vous doivent fusionner à nouveau n'importe quoi.
Par convention, la branche trunk peut représenter l'état actuel de votre développement, mais c'est pour un projet séquentiel simple, c'est-à-dire un projet qui a :
Parce qu'avec l'un (ou tous) de ces scénarios, vous obtenez quatre "troncs", quatre "développements en cours", et tout ce que vous faites dans ces développements parallèles ne devra pas nécessairement être fusionné dans le "tronc".
Dans SVN, une étiquette et une branche sont très similaires.
Étiquette \= une tranche de temps définie, généralement utilisée pour les versions.
Branche \= aussi une tranche de temps définie sur laquelle le développement peut se poursuivre, généralement utilisée pour les versions majeures telles que 1.0, 1.5, 2.0, etc, puis lorsque vous publiez, vous marquez la branche. Ceci vous permet de continuer à supporter une version de production tout en avançant avec des changements de rupture dans le tronc.
Tronçon \= espace de travail de développement, c'est là que tout le développement doit se faire, et que les changements sont fusionnés à partir des versions des branches.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
29 votes
Voici un bon article sur lequel je suis tombé et qui explique comment/quand utiliser trunk, branch, et tags. Je n'avais jamais utilisé le contrôle de source auparavant, mais cet article l'a rendu assez facile à comprendre pour un noob comme moi. Au jour le jour avec Subversion