Que signifient «branche», «tag» et «tronc» dans les référentiels Subversion?

J'ai beaucoup vu ces mots autour des discussions sur Subversion (et je suppose que le référentiel général).
J'utilise SVN pour mes projets depuis quelques années, mais je n'ai jamais compris le concept complet de ces répertoires.

Que signifient-ils?

Hmm, je ne suis pas sûr d'être d'accord avec le fait que Nick re tag soit similaire à une branche. Un tag n'est qu'un marqueur

• Le tronc serait le principal organe de développement, depuis le début du projet jusqu'à nos jours.

• La branche sera une copie du code dérivé d'un certain point dans le tronc qui est utilisé pour appliquer des modifications majeures au code tout en préservant l'intégrité du code dans le tronc. Si les changements majeurs fonctionnent conformément au plan, ils sont généralement fusionnés dans le coffre.

• Le tag sera un point dans le temps sur le tronc ou une branche que vous souhaitez conserver. Les deux principales raisons de la préservation seraient qu'il s'agit d'une version majeure du logiciel, qu'elle soit alpha, bêta, RC ou RTM, ou que c'est le point le plus stable du logiciel avant que des révisions majeures sur le coffre ne soient appliquées.

Dans les projets open source, les principales branches qui ne sont pas acceptées dans le tronc par les parties prenantes du projet peuvent devenir les bases de forks - par exemple, des projets totalement séparés qui partagent une origine commune avec d'autres codes sources.

Les sous-arbres de branche et de balise se distinguent du tronc des manières suivantes:

Subversion permet aux administrateurs système de créer des scripts de hook qui sont déclenchés pour exécution lorsque certains événements se produisent; par exemple, valider une modification du référentiel. Il est très courant qu'une implémentation de référentiel Subversion typique traite tout chemin contenant "/ tag /" à protéger en écriture après la création; le résultat net est que les balises, une fois créées, sont immuables (au moins pour les utilisateurs "ordinaires"). Cela se fait via les scripts de hook, qui renforcent l'immuabilité en empêchant d'autres modifications si la balise 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 fusion de branche" afin que les modifications validées dans une branche puissent être réintégrées dans le tronc avec la prise en charge de la fusion incrémentielle "intelligente".

Tout d'abord, comme le soulignent @AndrewFinnell et @KenLiu, dans SVN, les noms de répertoire eux-mêmes ne signifient rien - "tronc, branches et balises" sont simplement une convention commune utilisée par la plupart des référentiels. Tous les projets n'utilisent pas tous les répertoires (il est raisonnablement courant de ne pas utiliser de "balises" du tout), et en fait, rien ne vous empêche de les appeler comme vous voulez, bien que briser la convention soit souvent déroutant.

Je décrirai probablement le scénario d'utilisation le plus courant des branches et des balises, et je donnerai un exemple de scénario d'utilisation.

• Tronc : La principale zone de développement. C'est là que réside votre prochaine version majeure du code, et dispose généralement de toutes les nouvelles fonctionnalités.

• Branches : chaque fois que vous publiez une version majeure, une branche est créée. Cela vous permet de corriger les bogues et de créer une nouvelle version sans avoir à publier les fonctionnalités les plus récentes - éventuellement inachevées ou non testées.

• Tags : chaque fois que vous publiez une version (version finale, version candidate (RC) et bêta), vous créez un tag pour celle-ci. Cela vous donne une copie ponctuelle du code tel qu'il était à cet état, vous permettant de revenir en arrière et de reproduire les bogues si nécessaire dans une ancienne version, ou de rééditer une ancienne version exactement comme elle était. Les branches et les balises dans SVN sont légères - sur le serveur, il ne fait pas une copie complète des fichiers, juste un marqueur indiquant "ces fichiers ont été copiés lors de cette révision" qui ne prend que quelques octets. Dans cet esprit, vous ne devriez jamais vous soucier de créer une balise pour tout code publié. Comme je l'ai dit plus tôt, les balises sont souvent omises et, à la place, un journal des modifications ou un autre document clarifie le numéro de révision lorsqu'une version est effectuée.

Par exemple, disons que vous démarrez un nouveau projet. Vous commencez à travailler dans "trunk", sur ce qui sera finalement publié en version 1.0.

• trunk / - version de développement, bientôt 1.0
• branches / - vide

Une fois la version 1.0.0 terminée, vous branchez le tronc dans une nouvelle branche "1.0" et créez une balise "1.0.0". Maintenant, travaillez sur ce qui sera finalement 1.1 continue dans le tronc.

• trunk / - version de développement, bientôt 1.1
• branches / 1.0 - version 1.0.0
• tags / 1.0.0 - 1.0.0 version de sortie

Vous rencontrez des bogues dans le code, les corrigez dans le tronc, puis fusionnez les correctifs dans la branche 1.0. Vous pouvez également faire le contraire et corriger les bogues dans la branche 1.0, puis les fusionner à nouveau dans le tronc, mais les projets se limitent généralement à la fusion à sens unique pour réduire les risques de manquer quelque chose. Parfois, un bogue ne peut être corrigé qu'en 1.0 car il est obsolète en 1.1. Cela n'a pas vraiment d'importance: vous voulez seulement vous assurer que vous ne publiez pas 1.1 avec les mêmes bugs qui ont été corrigés dans 1.0.

• trunk / - version de développement, bientôt 1.1
• branches / 1.0 - prochaine version 1.0.1
• tags / 1.0.0 - 1.0.0 version de sortie

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 balise "1.0.1" à partir de la branche 1.0 et libérez le code. À ce stade, le tronc contiendra ce qui sera 1.1 et la branche "1.0" contient le code 1.0.1. La prochaine fois que vous publierez une mise à jour 1.0, ce sera 1.0.2.

• trunk / - version de développement, bientôt 1.1
• branches / 1.0 - prochaine version 1.0.2
• tags / 1.0.0 - 1.0.0 version de sortie
• tags / 1.0.1 - 1.0.1 version de sortie

Finalement, vous êtes presque prêt à publier la version 1.1, mais vous voulez d'abord faire une bêta. Dans ce cas, vous effectuez probablement une branche "1.1" et une balise "1.1beta1". Maintenant, le travail sur ce qui sera 1.2 (ou 2.0 peut-être) continue dans le tronc, mais le travail sur 1.1 continue dans la branche "1.1".

• trunk / - version de développement, bientôt 1.2
• branches / 1.0 - prochaine version 1.0.2
• branches / 1.1 - version 1.1.0 à venir
• tags / 1.0.0 - 1.0.0 version de sortie
• tags / 1.0.1 - 1.0.1 version de sortie
• tags / 1.1beta1 - version 1.1 beta 1

Une fois que vous avez publié la version 1.1 finale, vous créez une balise "1.1" à partir de la branche "1.1".

Vous pouvez également continuer à maintenir la version 1.0 si vous le souhaitez, en portant des corrections de bogues entre les trois branches (1.0, 1.1 et trunk). L'important est que pour chaque version principale du logiciel que vous gérez, vous disposez d'une branche qui contient la dernière version du code pour cette version.

Une autre utilisation des branches est pour les fonctionnalités. C'est là que vous branchez le tronc (ou l'une de vos branches de version) et travaillez sur une nouvelle fonctionnalité de manière isolée. Une fois la fonctionnalité terminée, vous la fusionnez et supprimez la branche.

• trunk / - version de développement, bientôt 1.2
• branches / 1.1 - version 1.1.0 à venir
• branches / ui-rewrite - branche de fonction expérimentale

L'idée est que vous travaillez sur quelque chose de perturbateur (qui empêcherait ou gênerait d'autres personnes de faire leur travail), quelque chose d'expérimental (qui pourrait même ne pas arriver), ou peut-être juste quelque chose qui prend beaucoup de temps (et vous avez peur que si elle contient une version 1.2 lorsque vous êtes prêt à créer une branche 1.2 à partir du tronc), vous pouvez le faire de manière isolée dans la branche. Généralement, vous le maintenez à jour avec le tronc en y fusionnant tout le temps les modifications, ce qui facilite la réintégration (fusionnez de nouveau dans le tronc) lorsque vous avez terminé.

Notez également que le schéma de versionnage que j'ai utilisé ici n'est que l'un des nombreux. Certaines équipes font des corrections de bogues / versions de maintenance comme 1.1, 1.2, etc., et des changements majeurs comme 1.x, 2.x, etc. L'utilisation ici est la même, mais vous pouvez nommer la branche "1" ou "1 .x "au lieu de" 1.0 "ou" 1.0.x ". (De plus, le versionnage sémantique est un bon guide sur la façon de faire les numéros de version).

En plus de ce que Nick a dit, vous pouvez en savoir plus sur Streamed Lines: Branching Patterns for Parallel Software Development

Dans cette figure mainest le tronc, rel1-maintest une branche et 1.0est une balise.

En général (vue indépendante de l'outil), une branche est le mécanisme utilisé pour le développement parallèle. Un SCM peut avoir de 0 à n branches. Subversion a 0.

• Trunk est une branche principale recommandée par Subversion , mais vous n'êtes en aucun cas obligé de la créer. Vous pourriez l'appeler «principal» ou «versions», ou pas du tout!

• La branche représente un effort de développement. Il ne doit jamais être nommé d'après une ressource (comme 'vonc_branch') mais après:

  • un objectif «myProject_dev» ou «myProject_Merge»
  • un périmètre de sortie 'myProjetc1.0_dev'or myProject2.3_Merge' ou 'myProject6..2_Patch1' ...

• La balise est un instantané des fichiers afin de revenir facilement à cet état. Le problème est que balise et 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 balise est définitive. Son contenu ne devrait jamais changer. JAMAIS. Déjà. Vous avez oublié une ligne dans la note de version? Créez une nouvelle balise. Obsolète ou supprimez l'ancien.

Maintenant, j'ai lu beaucoup de choses sur "la fusion de tel ou tel dans telle ou telle branche, puis finalement dans la branche du tronc". Cela s'appelle le flux de travail de fusion et il n'y a rien d'obligatoire ici . Ce n'est pas parce que vous avez une branche de tronc que vous devez fusionner quoi que ce soit.

Par convention, la branche trunk peut représenter l'état actuel de votre développement, mais c'est pour un simple projet séquentiel, c'est un projet qui a:

• pas de développement "à l'avance" (pour la préparation de la prochaine version suivante impliquant des changements tels qu'ils ne sont pas compatibles avec le développement "tronc" actuel)
• pas de refactoring massif (pour tester un nouveau choix technique)
• pas de maintenance à long terme d'une version précédente

Parce qu'avec 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 «tronc».

Dans SVN, une balise et une branche sont vraiment similaires.

Tag = une tranche définie dans le temps, généralement utilisée pour les versions

Branche = également une tranche définie dans le temps sur laquelle le développement peut continuer, généralement utilisé pour les versions majeures comme 1.0, 1.5, 2.0, etc., puis lorsque vous relâchez, vous balisez la branche. Cela vous permet de continuer à prendre en charge une version de production tout en allant de l'avant avec des changements de rupture dans le tronc

Trunk = espace de travail de développement, c'est là que tout développement doit avoir lieu, puis les modifications fusionnées à partir des versions de branche.

Ils n'ont pas vraiment de sens formel. Un dossier est un dossier vers SVN. Ils sont un moyen généralement accepté d'organiser votre projet.

• Le coffre est l'endroit où vous gardez votre ligne principale de développement. Le dossier de branche est l'endroit où vous pouvez créer, enfin, des branches, qui sont difficiles à expliquer dans un court article.

• Une branche est une copie d'un sous-ensemble de votre projet sur lequel vous travaillez séparément du tronc. Peut-être que c'est pour des expériences qui n'iront nulle part, ou peut-être pour la prochaine version, que vous fusionnerez plus tard dans le coffre quand elle deviendra stable.

• Et le dossier des balises sert à créer des copies balisées de votre référentiel, généralement aux points de contrôle de publication.

Mais comme je l'ai dit, pour SVN, un dossier est un dossier. branch, trunkEt l' étiquette sont juste une convention.

J'utilise généreusement le mot «copier». SVN ne fait pas de copies complètes des éléments dans le référentiel.

Le tronc est la ligne de développement qui contient le dernier code source et les dernières fonctionnalités. Il devrait contenir les dernières corrections de bogues ainsi que les dernières fonctionnalités ajoutées au projet.

Les branches sont généralement utilisées pour faire quelque chose loin du tronc (ou d'une autre ligne de développement) qui autrement casserait la construction. Les nouvelles fonctionnalités sont souvent intégrées dans une branche, puis fusionnées dans le coffre. Les branches contiennent souvent du code qui n'est pas nécessairement approuvé pour la ligne de développement à partir de laquelle il s'est ramifié. Par exemple, un programmeur pourrait essayer une optimisation sur quelque chose dans une branche et ne fusionner de nouveau dans la ligne de développement qu'une fois l'optimisation satisfaisante.

Les balises sont des instantanés du référentiel à un moment particulier. Aucun développement ne devrait se produire sur ces derniers. Ils sont le plus souvent utilisés pour prendre une copie de ce qui a été communiqué à un client afin que vous puissiez facilement accéder à ce qu'un client utilise.

Voici un lien vers un très bon guide des référentiels:

• Guide de contrôle des sources

Les articles de Wikipédia méritent également d'être lus.

C'est le problème du développement logiciel, il n'y a aucune connaissance cohérente sur quoi que ce soit, tout le monde semble l'avoir à sa façon, mais c'est parce que c'est une discipline relativement jeune de toute façon.

Voici ma façon simple et simple,

tronc - Le répertoire trunk contient le corps de travail le plus récent, approuvé et fusionné. Contrairement à ce que beaucoup ont avoué, mon coffre est uniquement destiné à un travail propre, soigné et approuvé, et non pas une zone de développement, mais plutôt une zone de libération.

À un moment donné, lorsque le coffre semble prêt à être libéré, il est étiqueté et libéré.

branches - Le répertoire branches contient des expériences et des travaux en cours. Le travail sous une branche y reste jusqu'à ce qu'il soit approuvé pour être fusionné dans le coffre. Pour moi, c'est le domaine où tout le travail est fait.

Par exemple: je peux avoir une branche itération-5 pour un cinquième cycle de développement sur le produit, peut-être une branche prototype-9 pour un neuvième cycle d'expérimentation, et ainsi de suite.

tags - Le répertoire tags contient des instantanés des branches approuvées et des versions de troncs. Chaque fois qu'une branche est approuvée pour fusionner dans le tronc, ou qu'une libération est faite du tronc, un instantané de la branche ou de la libération de tronc approuvée est fait sous les balises.

Je suppose qu'avec les balises, je peux faire des allers-retours dans le temps pour pointer des points d'intérêt assez facilement.

J'ai trouvé ce super tutoriel concernant SVN lorsque je recherchais le site Web de l' auteur du livre de recettes de programmation d'application de vision par ordinateur OpenCV 2 et j'ai pensé que je devrais le partager.

Il a un tutoriel sur la façon d'utiliser SVN et ce que signifient les expressions «tronc», «tag» et «branche».

Cité directement à partir de son tutoriel:

La version actuelle de votre projet logiciel, sur laquelle votre équipe travaille actuellement, se trouve généralement sous un répertoire appelé trunk . Au fur et à mesure que le projet évolue, le développeur met à jour cette version corrige des bugs, ajoute de nouvelles fonctionnalités) et soumet ses modifications sous ce répertoire.

À tout moment, vous souhaiterez peut-être geler une version et capturer un instantané du logiciel tel qu'il est à ce stade du développement. Cela correspond généralement aux versions officielles de votre logiciel, par exemple celles que vous livrerez à vos clients. Ces instantanés sont situés sous les balises répertoire des de votre projet.

Enfin, il est souvent utile de créer, à un moment donné, une nouvelle ligne de développement pour votre logiciel. Cela se produit, par exemple, lorsque vous souhaitez tester une implémentation alternative dans laquelle vous devez modifier votre logiciel mais que vous ne souhaitez pas soumettre ces modifications au projet principal jusqu'à ce que vous décidiez d'adopter la nouvelle solution. L'équipe principale peut ensuite continuer à travailler sur le projet tandis que d'autres développeurs travaillent sur le prototype. Vous mettriez ces nouvelles lignes de développement du projet dans un répertoire appelé branches .

Le répertoire trunk est le répertoire que vous connaissez probablement le mieux, car il est utilisé pour contenir les modifications les plus récentes. Votre base de code principale doit être dans le coffre.

Le répertoire des branches est destiné à contenir vos branches, quelles qu'elles soient.

Le répertoire des balises sert essentiellement à baliser un certain ensemble de fichiers. Vous faites cela pour des choses comme les versions, où vous voulez que "1.0" soit ces fichiers à ces révisions et "1.1" à ces fichiers à ces révisions. Vous ne modifiez généralement pas les balises une fois qu'elles sont créées. Pour plus d'informations sur les balises, reportez-vous au chapitre 4. Branchement et fusion (dans Version Control with Subversion ).

L'une des raisons pour lesquelles tout le monde a une définition légèrement différente est que Subversion n'implémente aucun support pour les branches et les balises. Subversion dit essentiellement: Nous avons examiné les branches et les balises complètes dans d'autres systèmes et ne les avons pas trouvées utiles, nous n'avons donc rien implémenté. Faites simplement une copie dans un nouveau répertoire avec une convention de nom à la place . Alors bien sûr, tout le monde est libre d'avoir des conventions légèrement différentes. Pour comprendre la différence entre une vraie balise et une simple convention de copie + dénomination, voir l'entrée Wikipédia Balises et branches Subversion .

Tag = une tranche définie dans le temps, généralement utilisée pour les versions

Je pense que c'est ce que l'on entend généralement par "tag". Mais dans Subversion:

Ils n'ont pas vraiment de sens formel. Un dossier est un dossier vers SVN.

ce que je trouve plutôt déroutant: un système de contrôle des révisions qui ne connaît rien aux branches ou aux balises. Du point de vue de l'implémentation, je pense que la manière de Subversion de créer des "copies" est très intelligente, mais je dois le savoir, c'est ce que j'appellerais une abstraction qui fuit .

Ou peut-être que j'utilise CVS depuis trop longtemps.

Je pense qu'une partie de la confusion vient de la différence entre le concept d'une balise et l'implémentation dans SVN. Pour SVN, une balise est une branche qui est une copie. La modification des balises est considérée comme incorrecte et en fait des outils comme TortoiseSVN vous avertiront si vous essayez de modifier quoi que ce soit avec ../tags/ .. dans le chemin.

Je ne suis pas vraiment sûr de ce qu'est une «balise», mais la branche est un concept de contrôle de source assez courant.

Fondamentalement, une branche est un moyen de travailler sur les modifications du code sans affecter le tronc. Supposons que vous souhaitiez ajouter une nouvelle fonctionnalité assez compliquée. Vous voulez pouvoir archiver les modifications au fur et à mesure que vous les apportez, mais vous ne voulez pas qu'elles affectent le tronc tant que vous n'avez pas terminé avec la fonctionnalité.

Vous devez d'abord créer une branche. Il s'agit essentiellement d'une copie du tronc au moment où vous avez créé la branche. Vous feriez alors tout votre travail dans la branche. Toutes les modifications apportées dans la branche n'affectent pas le tronc, donc le tronc est toujours utilisable, permettant aux autres de continuer à y travailler (comme faire des corrections de bugs ou de petites améliorations). Une fois votre fonctionnalité terminée, vous réintégrez la branche dans le tronc. Cela déplacerait toutes vos modifications de la branche vers le tronc.

Il existe un certain nombre de modèles que les gens utilisent pour les succursales. Si vous avez un produit avec plusieurs versions principales prises en charge à la fois, chaque version est généralement une branche. Là où je travaille, nous avons une branche QA et une branche Production. Avant de publier notre code dans QA, nous intégrons les modifications à la branche QA, puis déployons à partir de là. Lors de la sortie en production, nous intégrons de la branche QA à la branche Production, nous savons donc que le code en cours de production est identique à ce que le QA a testé.

Voici l'entrée Wikipedia sur les branches , car elles expliquent probablement mieux que moi les choses. :)

Tronc : Après la fin de chaque sprint en agile, nous sortons avec un produit partiellement livrable. Ces versions sont conservées dans le coffre.

Branches : Tous les codes de développement parallèle pour chaque sprint en cours sont conservés dans les branches.

Tags : chaque fois que nous publions une version bêta du produit partiellement livrable, nous en faisons un tag. Cela nous donne le code qui était disponible à ce moment-là, nous permettant de revenir à cet état si nécessaire à un moment donné du développement.

Pour les personnes familiarisées avec GIT, master in GIT est équivalent à trunk in SVN.

La branche et la balise ont la même terminologie dans GIT et SVN.