Que signifient «branch», «tag» et «trunk» dans les repositorys Subversion?

J’ai beaucoup vu ces mots autour des discussions de Subversion (et je suppose que le référentiel général). J’ai utilisé 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?

Hmm, je ne suis pas sûr que Nick Re Tag soit similaire à une twig. Une balise est juste un marqueur

  • Le tronc serait le corps principal du développement, à partir du début du projet jusqu’à présent.

  • Branchement sera une copie du code dérivé d’un certain sharepoint la ligne réseau, utilisé pour appliquer des modifications majeures au code tout en préservant l’intégrité du code dans la ligne. Si les changements majeurs fonctionnent conformément au plan, ils sont généralement fusionnés dans le coffre.

  • Tag sera un point sur le tronc ou une twig que vous souhaitez conserver. Les deux principales raisons de la préservation seraient que ce soit une version majeure du logiciel, que ce soit alpha, bêta, RC ou RTM, ou le point le plus stable du logiciel avant que des révisions majeures du tronc soient appliquées.

Dans les projets open source, les principales twigs qui ne sont pas acceptées dans la jonction par les parties prenantes du projet peuvent devenir les bases des forks , par exemple des projets totalement distincts partageant une origine commune avec d’autres codes sources.

Tout d’abord, comme le soulignent @AndrewFinnell et @KenLiu, dans SVN, les noms de répertoires eux-mêmes ne veulent rien dire – “tronc, twigs et tags” 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 assez courant de ne pas utiliser de “tags”) et, en fait, rien ne vous empêche de les appeler comme vous le souhaitez, bien que les conventions soient souvent déroutantes.

Je décrirai probablement le scénario d’utilisation le plus courant des twigs et des étiquettes, et je donnerai un exemple de scénario d’utilisation.

  • Tronc : la zone de développement principale. C’est là que vit votre prochaine version majeure du code, et présente généralement toutes les fonctionnalités les plus récentes.

  • Branches : chaque fois que vous publiez une version majeure, une twig est créée. Cela vous permet de faire des corrections de bogues et de faire une nouvelle version sans avoir à publier les nouvelles fonctionnalités – probablement inachevées ou non testées.

  • Tags : Chaque fois que vous publiez une version (version finale, version candidate (RC) et version bêta), vous en faites un tag. 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 telle qu’elle était. Les twigs 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 disant “ces fichiers ont été copiés à cette révision” qui ne prend que quelques octets. Dans cette optique, vous ne devriez jamais vous soucier de créer une balise pour un code publié. Comme je l’ai dit plus tôt, les balises sont souvent omises et à la place, un journal des changements ou un autre document précise le numéro de révision lorsqu’une version est faite.


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

  • trunk / – version de développement, bientôt 1.0
  • twigs / – vide

Une fois la version 1.0.0 terminée, vous twigz le tronc dans une nouvelle twig “1.0” et créez une balise “1.0.0”. Maintenant, travailler sur ce qui sera éventuellement 1.1 continue dans le tronc.

  • trunk / – version de développement, bientôt 1.1
  • twigs / 1.0 – version 1.0.0
  • tags / 1.0.0 – version 1.0.0

Vous rencontrez des bogues dans le code et les corrigez dans la jonction, puis fusionnez les correctifs avec la twig 1.0. Vous pouvez également faire le contraire, et corriger les bogues dans la twig 1.0, puis les fusionner dans le tronc, mais les projets s’en tiennent souvent à la fusion unidirectionnelle pour réduire les risques de manquer quelque chose. Parfois, un bogue ne peut être corrigé que dans la version 1.0, car il est obsolète dans la version 1.1. Cela n’a pas vraiment d’importance: vous voulez seulement vous assurer de ne pas publier la version 1.1 avec les mêmes bogues corrigés dans la version 1.0.

  • trunk / – version de développement, bientôt 1.1
  • twigs / 1.0 – version 1.0.1 à venir
  • tags / 1.0.0 – version 1.0.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. Donc, vous faites un tag “1.0.1” de la twig 1.0 et libérez le code. À ce stade, le tronc contiendra ce qui sera 1.1, et la twig “1.0” contient le code 1.0.1. La prochaine fois que vous publiez une mise à jour à 1.0, ce serait 1.0.2.

  • trunk / – version de développement, bientôt 1.1
  • twigs / 1.0 – version 1.0.2 à venir
  • tags / 1.0.0 – version 1.0.0
  • tags / 1.0.1 – Version 1.0.1

Finalement, vous êtes presque prêt à sortir la version 1.1, mais vous voulez d’abord faire une version bêta. Dans ce cas, vous faites probablement une twig “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 twig “1.1”.

  • trunk / – version de développement, bientôt 1.2
  • twigs / 1.0 – version 1.0.2 à venir
  • twigs / 1.1 – version 1.1.0 à venir
  • tags / 1.0.0 – version 1.0.0
  • tags / 1.0.1 – Version 1.0.1
  • tags / 1.1beta1 – version 1.1 bêta 1

Une fois la version 1.1 finale publiée, vous faites une balise “1.1” à partir de la twig “1.1”.

Vous pouvez également continuer à gérer la version 1.0 si vous le souhaitez, en portant des corrections de bogues entre les trois twigs (1.0, 1.1 et le tronc). Le point important à retenir est que pour chaque version principale du logiciel que vous gérez, vous avez une twig contenant la dernière version du code de cette version.


Une autre utilisation des twigs concerne les fonctionnalités. C’est là que vous twigz le tronc (ou l’une de vos twigs de publication) et travaillez sur une nouvelle fonctionnalité de manière isolée. Une fois la fonctionnalité terminée, vous la fusionnez et supprimez la twig.

  • trunk / – version de développement, bientôt 1.2
  • twigs / 1.1 – version 1.1.0 à venir
  • twigs / ui-rewrite – twig expérimentale

L’idée est que lorsque vous travaillez sur quelque chose de perturbateur (qui empêcherait ou empêcherait les autres de faire leur travail), quelque chose d’expérimental (qui peut même ne pas arriver), ou peut-être juste quelque chose qui prend du temps (Et vous craignez que si vous tenez une version 1.2 lorsque vous êtes prêt à créer une twig 1.2 à partir du tronc), vous pouvez le faire isolément dans une twig. Généralement, vous le gardez à jour avec le tronc en fusionnant les modifications à tout moment, ce qui facilite la réintégration (fusion vers le tronc) lorsque vous avez terminé.


Notez également que le système de gestion des versions que j’ai utilisé ici est l’un des nombreux. Certaines équipes feraient des corrections / corrections de bogues en 1.1, 1.2, etc., et des modifications majeures comme 1.x, 2.x, etc. L’utilisation est la même, mais vous pouvez nommer la twig “1” ou “1”. .x “au lieu de” 1.0 “ou” 1.0.x “. (Par ailleurs, le contrôle de version 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 les lignes diffusées en continu: Modèles de twigment pour le développement de logiciels parallèles

entrer la description de l'image ici

Dans cette figure, main est le tronc, rel1-maint est une twig et 1.0 est une balise.

En général (vue indépendante des outils), une twig est le mécanisme utilisé pour le développement parallèle. Un SCM peut avoir de 0 à n twigs. Subversion a 0.

  • La jonction est une twig principale recommandée par Subversion , mais vous n’êtes en aucun cas obligé de la créer. Vous pourriez l’appeler «main» ou «release», ou ne pas en avoir du tout!

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

    • un but ‘myProject_dev’ ou ‘myProject_Merge’
    • un périmètre de publication ‘myProjetc1.0_dev’or myProject2.3_Merge’ ou ‘myProject6..2_Patch1’ …
  • Tag est un instantané des fichiers afin de revenir facilement à cet état. Le problème est que la balise et la twig 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’access fournis avec Subversion pour empêcher quiconque de faire autre chose que créer de nouvelles copies dans la zone des balises.

Un tag est final. Son contenu ne devrait jamais changer. JAMAIS. Déjà. Vous avez oublié une ligne dans la note de publication? Créez une nouvelle balise. Obsolète ou enlève l’ancien.

Maintenant, je lis beaucoup sur “la fusion telle ou telle dans telle ou telle twig, puis finalement dans la twig du tronc”. Cela s’appelle un stream de travail de fusion et rien n’est obligatoire ici . Ce n’est pas parce que vous avez une twig de tronc que vous devez fusionner .

Par convention, la twig du tronc 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:

  • pas de développement “en avance” (pour la préparation de la prochaine version suivante impliquant de tels changements, ils ne sont pas compatibles avec le développement “trunk” actuel)
  • pas de refactoring massif (pour tester un nouveau choix technique)
  • pas de maintenance à long terme d’une version précédente

Car avec un (ou tous) de ces scénarios, vous obtenez quatre «troncs», quatre «développements actuels» et tout ce que vous ne ferez pas dans ce développement parallèle devra nécessairement être fusionné en «tronc».

En SVN, un tag et une twig sont vraiment similaires.

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

Branch = également une tranche définie dans le temps pendant laquelle le développement peut continuer, généralement utilisé pour les versions majeures telles que 1.0, 1.5, 2.0, etc. Cela vous permet de continuer à prendre en charge une version de production tout en avançant les 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 twig.

Ils n’ont pas vraiment de sens formel. Un dossier est un dossier à SVN. Ils sont un moyen généralement accepté pour organiser votre projet.

  • Le tronc est l’endroit où vous conservez votre principale ligne de développement. Le dossier de twig est l’endroit où vous pouvez créer, enfin, des twigs difficiles à expliquer dans un court message.

  • Une twig 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 ne vont pas n’importe où, ou peut-être pour la prochaine version, que vous fusionnerez plus tard dans le coffre quand il deviendra stable.

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

Mais comme je l’ai dit, pour SVN, un dossier est un dossier. branch , trunk et tag ne sont qu’une convention.

J’utilise le mot ‘copy’ libéralement. SVN ne fait pas de copies complètes des éléments dans le référentiel.

La ligne réseau est la ligne de développement qui contient le code source et les fonctionnalités les plus récents. Il devrait contenir les dernières corrections de bogues ainsi que les dernières fonctionnalités ajoutées au projet.

Les twigs sont généralement utilisées pour faire quelque chose en dehors de la ligne de réseau (ou de toute autre ligne de développement) qui briserait autrement la construction. Les nouvelles fonctionnalités sont souvent intégrées dans une twig puis fusionnées dans le coffre. Les succursales contiennent souvent du code qui n’est pas nécessairement approuvé pour la ligne de développement dont il est issu. Par exemple, un programmeur peut essayer une optimisation sur quelque chose dans une twig et ne réintégrer la ligne de développement que lorsque l’optimisation est satisfaisante.

Les balises 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é publié sur un client afin que vous puissiez facilement accéder à ce que le client utilise.

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

  • HOWTO sur le contrôle des sources

Les articles sur Wikipedia valent également la peine d’être lus.

Maintenant, c’est le développement logiciel, il n’y a pas de connaissances cohérentes sur tout, tout le monde semble l’avoir à sa façon, mais c’est parce que c’est une discipline relativement jeune.

Voici mon moyen simple,

trunk – Le répertoire trunk contient le corps de travail le plus récent, approuvé et fusionné. Contrairement à ce que beaucoup ont avoué, ma malle est uniquement destinée à un travail propre, soigné et approuvé, et non à une zone de développement, mais plutôt à une zone de dégagement.

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

twigs – Le répertoire des twigs contient des expériences et des travaux en cours. Le travail sous une twig rest là 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 twig d’ itération-5 pour un cinquième cycle de développement sur le produit, peut-être une twig prototype-9 pour un neuvième cycle d’expérimentation, etc.

tags – Le répertoire tags contient des instantanés des twigs et des versions de trunk approuvées. Chaque fois qu’une twig est approuvée pour fusionner dans la jonction ou qu’une version est faite de la jonction, un instantané de la version approuvée de la twig ou de la jonction est créé sous les balises.

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

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

Le répertoire des succursales permet de conserver vos succursales, 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 lors de ces révisions et “1.1” ces fichiers lors de ces révisions. En général, vous ne modifiez pas les tags une fois qu’ils ont été créés. Pour plus d’informations sur les balises, reportez-vous au chapitre 4. Branchement et fusion (dans Version Control avec Subversion ).

L’une des raisons pour lesquelles tout le monde a une définition légèrement différente est que Subversion implémente un support zéro pour les twigs et les tags. Subversion dit essentiellement: Nous avons examiné les twigs et les balises complètes des autres systèmes et nous ne les avons pas trouvés 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 balise réelle et une simple convention de copie et de dénomination, consultez l’entrée Wikipedia Subversion tags & twigs .

J’ai trouvé ce bon tutoriel concernant SVN lorsque je cherchais le site Web de l’ auteur du livre de recettes de programmation d’applications OpenCV 2 Computer Vision et j’ai pensé que je devais partager.

Il a un tutoriel sur l’utilisation de SVN et ce que signifient les expressions «trunk», «tag» et «branch».

Cité directement depuis 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 . À mesure que le projet évolue, le développeur met à jour cette version pour corriger les bogues, append de nouvelles fonctionnalités et soumettre ses modifications sous ce répertoire.

À tout moment, vous pouvez souhaiter 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 le répertoire tags de votre projet.

Enfin, il est souvent utile de créer, à un moment donné, une nouvelle ligne de développement pour vos logiciels. Cela se produit, par exemple, lorsque vous souhaitez tester une autre implémentation dans laquelle vous devez modifier votre logiciel, mais vous ne souhaitez pas soumettre ces modifications au projet principal tant que vous n’avez pas décidé d’adopter la nouvelle solution. L’équipe principale peut alors continuer à travailler sur le projet tandis que d’autres développeurs travaillent sur le prototype. Vous metsortingez ces nouvelles lignes de développement du projet sous un répertoire appelé twigs .

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 à SVN.

ce que je trouve plutôt déroutant: un système de contrôle de révision qui ne sait rien des twigs ou des tags. Du sharepoint vue de la mise en œuvre, je pense que la manière de créer des “copies” de Subversion est très intelligente, mais ce que j’appellerais une abstraction qui fuit .

Ou peut-être que je viens d’utiliser CVS beaucoup trop longtemps.

Je pense qu’une partie de la confusion vient de la différence entre le concept d’une balise et la mise en œuvre dans SVN. Pour SVN, un tag est une twig qui est une copie. La modification de balises est considérée comme incorrecte et, en fait, des outils comme TortoiseSVN vous avertiront si vous tentez de modifier quelque chose avec ../tags/ .. dans le chemin.

Je ne suis pas vraiment sûr de ce qu’est «tag», mais la twig est un concept de contrôle de source assez commun.

Fondamentalement, une twig est un moyen de travailler sur les modifications apscopes au code sans affecter le tronc. Disons que vous voulez append une nouvelle fonctionnalité assez compliquée. Vous souhaitez être en mesure d’enregistrer les modifications au fur et à mesure que vous les effectuez, mais vous ne voulez pas qu’elles affectent le tronc tant que vous n’en avez plus besoin.

D’abord, vous créez une twig. Il s’agit d’une copie du tronc à partir du moment où vous avez créé la twig. Vous feriez alors tout votre travail dans la twig. Toutes les modifications apscopes à la twig n’affectent pas le tronc, donc le trunk 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 twig dans le coffre. Cela déplacerait toutes vos modifications de la twig au tronc.

Il existe un certain nombre de modèles que les gens utilisent pour les succursales. Si vous avez un produit avec plusieurs versions majeures sockets en charge en même temps, chaque version est généralement une twig. Là où je travaille, nous avons une twig QA et une twig Production. Avant de publier notre code pour QA, nous intégrons les modifications à la twig QA, puis nous déployons à partir de là. Lors de la mise en production, nous intégrons la twig QA à la twig Production. Nous soaps donc que le code en cours de production est identique à celui testé.

Voici l’entrée de Wikipedia sur les twigs , car elles expliquent probablement mieux les choses que moi. 🙂

La jonction est le dossier de base du code de votre application. C’est ici que vous travaillez sur votre prochaine version / version.

Branch est un dossier qui vous permet de choisir un moment dans le temps et de suivre un chemin de développement différent de celui de / Trunk. Une utilisation courante de Branch est de fournir à votre équipe de développement l’access à un instantané actuel de votre application tel qu’il existe dans la production, c.-à-d. / Direction / production-maintenance.

Ce concept de «twigment» permet à votre équipe de créer des correctifs / améliorations en production, sans affecter le travail en cours pour votre prochaine version, qui se déroule actuellement dans / Trunk. Les twigs peuvent également être des mini-fonctionnalités qui, dans les grandes équipes, permettent aux développeurs de travailler de manière atomique et de fusionner dans / Trunk à un moment donné.

Tags est un dossier qui vous permet de prendre des instantanés de votre application et de ne travailler qu’avec ces “builds” spécifiques. Cela permet à votre équipe de faire preuve de souplesse, à la fois dans les tests et dans la recherche des différences entre les builds. Vous trouverez souvent une convention de dénomination suivie dans / Branch, qui se rapporte à vos builds, c.-à-d. /Branch/2.0.0, /Branch/2.0.1, /Branch/3.1.0 , etc. La convention de nommage est à vous et à votre équipe. rest cohérent!

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

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

Tags : Chaque fois que nous publions une version bêta d’un produit partiellement expédiable, 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 au cours du développement.

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

Branch and tag a la même terminologie dans GIT et SVN.