Que signifient « branche », « balise » et « tronc » dans les dépôts Subversion ?

https://stackoverflow.com/questions/16142

08-06-2019
|

Question

J'ai souvent vu ces mots dans les discussions sur Subversion (et je suppose sur le référentiel général).J'utilise SVN pour mes projets ces dernières années, mais je n'ai jamais compris le concept complet de ces répertoires.

Que signifient-ils?

La solution

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

Tronc serait l'essentiel du développement, depuis le début du projet jusqu'à aujourd'hui.
Bifurquer sera une copie du code dérivé d'un certain point du 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 comme prévu, ils sont généralement réintégrés dans le tronc.
Étiqueter sera un point dans le temps sur le tronc ou une branche que vous souhaitez conserver.Les deux principales raisons de préservation seraient qu'il s'agit soit d'une version majeure du logiciel, qu'elle soit alpha, bêta, RC ou RTM, soit du point le plus stable du logiciel avant l'application de révisions majeures sur le tronc.

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 la base de fourchettes -- par exemple, des projets totalement séparés qui partagent une origine commune avec un autre code source.

Les sous-arbres de branche et de balise se distinguent du tronc de la manière suivante :

Subversion permet aux administrateurs système de créer scripts de crochet dont l'exécution est déclenchée lorsque certains événements se produisent ;par exemple, valider une modification dans le référentiel.Il est très courant qu'une implémentation typique d'un dépôt Subversion traite tout chemin contenant "/tag/" comme étant protégé en écriture après sa création ;le résultat net est que les balises, une fois créées, sont immuables (du moins pour les utilisateurs "ordinaires").Cela se fait via les scripts hook, qui renforcent l'immuabilité en empêchant d'autres modifications si étiqueter est un nœud parent de l'objet modifié.

Subversion a également ajouté des fonctionnalités, depuis la version 1.5, liées au « suivi des fusions de branches » afin que les modifications apportées à un bifurquer peuvent être fusionnés à nouveau dans le tronc avec prise en charge d'une fusion incrémentielle et « intelligente ».

Autres conseils

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

Je vais probablement décrire le scénario d'utilisation le plus courant des branches et des balises, et donner un exemple de scénario de la façon dont elles sont utilisées.

Tronc:Le principal domaine de développement.C’est là que se trouve votre prochaine version majeure du code et contient généralement toutes les fonctionnalités les plus récentes.
Branches:Chaque fois que vous publiez une version majeure, une branche est créée.Cela vous permet de corriger des 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.
Mots clés:Chaque fois que vous publiez une version (version finale, versions candidates (RC) et bêta), vous créez une balise 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 version antérieure, ou de rééditer une version antérieure exactement telle qu'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 publiée.

Par exemple, disons que vous démarrez un nouveau projet.Vous commencez à travailler en "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, le travail sur ce qui sera finalement la version 1.1 se poursuit dans le coffre.

tronc/ - version de développement, bientôt la 1.1
branches/1.0 - version 1.0.0
balises/1.0.0 - version 1.0.0

Vous rencontrez des bogues dans le code, les corrigez dans le coffre, puis fusionnez les correctifs vers la branche 1.0.Vous pouvez également faire l'inverse et corriger les bogues dans la branche 1.0, puis les fusionner dans le tronc, mais généralement les projets s'en tiennent à la fusion unidirectionnelle uniquement pour réduire le risque de manquer quelque chose.Parfois, un bug ne peut être corrigé qu'en 1.0 car il est obsolète en 1.1.Ce n'est pas vraiment grave :vous voulez seulement vous assurer que vous ne publiez pas la version 1.1 avec les mêmes bogues qui ont été corrigés dans la version 1.0.

trunk/ - version de développement, bientôt 1.1
succursales/1.0 - prochaine version 1.0.1
balises/1.0.0 - version 1.0.0

Une fois que vous avez trouvé suffisamment de bugs (ou peut-être un bug critique), vous décidez de publier une version 1.0.1.Vous créez donc une balise "1.0.1" à partir de la branche 1.0 et publiez 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 vers la version 1.0, ce sera la 1.0.2.

trunk/ - version de développement, bientôt 1.1
succursales/1.0 - prochaine version 1.0.2
balises/1.0.0 - version 1.0.0
balises/1.0.1 - version 1.0.1

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

tronc/ - version de développement, bientôt la 1.2
branches/1.0 - prochaine version 1.0.2
branches/1.1 - prochaine version 1.1.0
balises/1.0.0 - version 1.0.0
balises/1.0.1 - version 1.0.1
tags/1.1beta1 - version 1.1 bêta 1

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

Vous pouvez également continuer à maintenir la version 1.0 si vous le souhaitez, en transférant les corrections de bogues entre les trois branches (1.0, 1.1 et trunk).Le point important à retenir 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 concerne les fonctionnalités.C'est ici 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 à nouveau et supprimez la branche.

trunk/ - version de développement, bientôt 1.2
branches/1.1 - prochaine version 1.1.0
branches/ui-rewrite - branche de fonctionnalités expérimentales

L'idée est que vous travaillez sur quelque chose de perturbateur (qui empêcherait ou empêcherait d'autres personnes de faire leur travail), quelque chose d'expérimental (qui pourrait même ne pas être intégré), ou peut-être simplement quelque chose qui prend beaucoup de temps. (et vous avez peur si cela bloque 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 une branche.Généralement, vous le maintenez à jour avec le tronc en y fusionnant les modifications à tout moment, ce qui facilite la réintégration (fusion avec le coffre) lorsque vous avez terminé.

Notez également que le schéma de gestion des versions que j'ai utilisé ici n'est qu'un parmi tant d'autres.Certaines équipes effectueraient des versions de correction de bugs/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 côté, versionnement 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 Lignes diffusées :Modèles de branchement pour le développement de logiciels parallèles

enter image description here

Dans cette figure main c'est le coffre, rel1-maint est une branche et 1.0 est une balise.

En général (vue indépendante 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.

Tronc est une branche principale recommandé par Subversion, mais vous n'êtes en aucun cas obligé de le créer.Vous pourriez l'appeler « versions principales » ou « versions », ou ne pas en avoir du tout !
Bifurquer 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 version 'myProjetc1.0_dev' ou myProject2.3_Merge' ou 'myProject6..2_Patch1'...
Étiqueter est un instantané des fichiers afin de revenir facilement à cet état.Le problème est que la balise 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 balise est définitive.Son contenu ne devrait jamais changer.JAMAIS.Jamais.Vous avez oublié une ligne dans la note de version ?Créez une nouvelle balise.Obsolète ou supprimer l'ancien.

Maintenant, j'ai beaucoup lu sur "la fusion de tel ou tel dans telle ou telle branche, puis enfin dans la branche tronc".Que l'on appelle fusionner le flux de travail et voici rien d'obligatoire ici.Ce n'est pas parce que vous avez une branche principale que vous je dois fusionner rien.

Par convention, la branche tronc peut représenter l'état actuel de votre développement, mais il s'agit d'un simple projet séquentiel, c'est-à-dire un projet qui a :

pas de développement 'en avance' (pour la préparation de la prochaine version impliquant de tels changements 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 actuels », 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 balise et une branche sont vraiment similaires.

Étiqueter = une tranche de temps définie, généralement utilisée pour les sorties

Bifurquer = également une tranche de temps définie sur laquelle le développement peut continuer, généralement utilisée pour les versions majeures comme 1.0, 1.5, 2.0, etc., puis lorsque vous publiez, vous marquez la branche.Cela vous permet de continuer à prendre en charge une version de production tout en progressant avec les changements majeurs dans le tronc.

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

Ils n’ont pas vraiment de signification formelle.Un dossier est un dossier de SVN.Ils constituent une manière généralement acceptée d’organiser votre projet.

Le coffre est l’endroit où vous conservez votre principale ligne de développement.Le dossier de branche est l'endroit où vous pouvez créer des branches, 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.C'est peut-être pour des expériences qui pourraient ne mener nulle part, ou peut-être pour la prochaine version, que vous fusionnerez plus tard dans le coffre lorsqu'elle sera stable.
Et le dossier tags 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, trunk et tag ne sont qu'une convention.

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

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

Le branches sont généralement utilisés pour faire quelque chose en dehors du tronc (ou d'une autre ligne de développement) qui autrement casser la construction.Les nouvelles fonctionnalités sont souvent créées dans une branche, puis fusionnées dans le tronc.Les branches contiennent souvent du code qui n'est pas nécessairement approuvé pour la ligne de développement à partir de laquelle elles sont dérivées.Par exemple, un programmeur pourrait essayer une optimisation sur quelque chose dans une branche et ne réintégrer la ligne de développement qu'une fois que l'optimisation est satisfaisante.

Le Mots clés sont des instantanés du référentiel à un moment donné.Aucun développement ne devrait avoir lieu sur ceux-ci.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 :

HOWTO sur le contrôle de source

Les articles de Wikipédia valent également la peine d'être lus.

C'est le problème du développement logiciel : il n'y a pas de connaissances cohérentes sur quoi que ce soit, chacun semble avoir sa propre voie, mais c'est de toute façon parce que c'est une discipline relativement jeune.

Voici ma manière simple,

tronc - Le répertoire principal contient l'ensemble des travaux les plus récents, approuvés et fusionnés.Contrairement à ce que beaucoup ont avoué, ma malle est uniquement destinée à des travaux propres, soignés, approuvés, 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 alors étiqueté et libéré.

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

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

Mots clés - Le répertoire des balises contient des instantanés des branches et des versions de tronc approuvées.Chaque fois qu'une branche est approuvée pour fusionner dans le tronc, ou qu'une version est créée à partir du tronc, un instantané de la branche ou de la version de tronc approuvée est créé sous les balises.

Je suppose qu'avec les balises, je peux aller et venir dans le temps jusqu'aux points d'intérêt assez facilement.

J'ai trouvé cet excellent tutoriel concernant SVN lorsque je cherchais le site Web du auteur de la OuvrirCV 2 Computer Vision Application Programming Cookbook et j'ai pensé que je devrais le partager.

Il propose un didacticiel expliquant comment utiliser SVN et ce que signifient les expressions « tronc », « balise » et « branche ».

Cité directement de son tutoriel :

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

À tout moment, vous souhaiterez peut-être geler une version et capturer un instantané du logiciel tel qu'il se trouve à ce stade du développement.Cela correspond généralement aux versions officielles de vos logiciels, par exemple celles que vous livrerez à vos clients.Ces instantanés sont situés sous le Mots clés répertoire 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 si vous adoptez la nouvelle solution.L'équipe principale peut alors continuer à travailler sur le projet pendant que d'autres développeurs travaillent sur le prototype.Vous placeriez 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 sert à conserver vos succursales, quelles qu'elles soient.

Le répertoire tags 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" soit 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, voir Chapitre 4.Branchement et fusion (dans Contrôle de version avec Subversion).

L'une des raisons pour lesquelles chacun a une définition légèrement différente est que Subversion implémente zéro prise en charge des branches et des balises.Subversion dit essentiellement : Nous avons examiné complet branches et balises dans d’autres systèmes et ne les avons pas trouvés utiles, nous n’avons donc rien implémenté.Faites simplement une copie dans un nouveau répertoire avec un nom convention plutôt.Bien sûr, chacun est libre d’avoir des conventions légèrement différentes.Pour comprendre la différence entre un réel Tag et une simple copie + convention de dénomination voir l'entrée Wikipedia Balises et branches Subversion.

Tag = une tranche de temps définie, généralement utilisée pour les sorties

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

Ils n’ont pas vraiment de signification formelle.Un dossier est un dossier sur SVN.

ce que je trouve plutôt déroutant :un système de contrôle de révision qui ne sait rien des branches ou des balises.Du point de vue de l'implémentation, je pense que la manière Subversion de créer des "copies" est très intelligente, mais le fait d'en avoir connaissance est ce que j'appellerais un abstraction qui fuit.

Ou peut-être que j'utilise simplement CVS beaucoup trop long.

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

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

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

Vous créeriez d’abord 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 succursale.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égrerez 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 disposez d'un produit avec plusieurs versions majeures prises en charge simultanément, chaque version constitue généralement une branche.Là où je travaille, nous avons une branche QA et une branche Production.Avant de publier notre code au QA, nous intégrons les modifications dans la branche QA, puis déployons à partir de là.Lors de la mise en production, nous intégrons la branche QA à la branche Production, nous savons donc que le code exécuté en production est identique à celui testé par l'AQ.

Ici se trouve le Entrée Wikipédia sur les branches, car ils expliquent probablement les choses mieux que moi.:)

Pour les personnes familiarisées avec GIT, master dans GIT équivaut à trunk dans SVN.

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

Tronc :Après l'achèvement 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éveloppements parallèles pour chaque sprint en cours sont conservés dans des branches.

Mots clés :Chaque fois que nous publions une version bêta d'un produit partiellement livrable, nous créons une balise pour celui-ci.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.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow