Question Que signifient "branch", "tag" et "trunk" dans les dépôts Subversion?


J'ai beaucoup vu ces mots autour des discussions de Subversion (et je suppose que c'est 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?


1131
2017-08-19 13:22


origine


Réponses:


Hmm, je ne suis pas sûr d'être d'accord avec Nick re tag étant similaire à une branche. Une étiquette est juste un marqueur

  • Tronc serait le principal axe de 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 modifications majeures fonctionnent conformément au plan, elles sont généralement fusionnées dans le coffre.

  • Marque 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 soit une version majeure du logiciel, qu'il s'agisse d'alpha, beta, RC ou RTM, ou c'est le point le plus stable du logiciel avant que des révisions majeures sur le tronc 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 fourches - par exemple, des projets totalement distincts qui partagent une origine commune avec un autre code source.


864
2017-08-19 13:35



Tout d'abord, comme le soulignent @AndrewFinnell et @ KenLiu, dans SVN, les noms de répertoires eux-mêmes ne veulent rien dire - "tronc, branches et balises" 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 commun de ne pas utiliser de "balises"), et en fait, rien ne vous empêche de les appeler comme vous le souhaitez, bien que la rupture des conventions soit souvent source de confusion.

Je vais décrire probablement 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 ils sont utilisés.

  • Tronc: Le principal domaine de développement. C'est là que votre prochaine version majeure du code vit, et a 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 d'effectuer des corrections de bogues et de créer une nouvelle version sans avoir à publier les nouvelles fonctionnalités, éventuellement inachevées ou non testées.

  • Mots clés: Chaque fois que vous publiez une version (version finale, version candidate (RC) et betas), vous en faites un tag. Cela vous donne une copie ponctuelle du code tel qu'il était à cet état, ce qui vous permet de revenir en arrière et de reproduire des bogues si nécessaire dans une version antérieure, ou de rééditer une version antérieure exactement comme elle l'é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 être préoccupé par la création d'un tag 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 faite.


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 la ligne de réseau dans une nouvelle branche "1.0" et créez une balise "1.0.0". Maintenant, travailler sur ce qui sera finalement 1.1 continue dans le coffre.

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

Vous rencontrez des bogues dans le code, et les corrigez dans le tronc, puis fusionnez les corrections sur la branche 1.0. Vous pouvez également faire le contraire, et corriger les bogues dans la branche 1.0, puis les fusionner de nouveau au tronc, mais généralement les projets se contentent de fusionner unidirectionnel seulement 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. Cela n'a pas vraiment d'importance: vous voulez seulement vous assurer que vous ne libérez 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
  • branches / 1.0 - prochaine version 1.0.1
  • tags / 1.0.0 - 1.0.0 version

Une fois que vous avez trouvé assez de bogues (ou peut-être un bug critique), vous décidez de faire une version 1.0.1. Donc vous faites un tag "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" contiendra le code 1.0.1. La prochaine fois que vous diffuserez 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
  • tags / 1.0.1 - 1.0.1 version de publication

Finalement, vous êtes presque prêt à lancer la version 1.1, mais vous voulez d'abord faire une version bêta. Dans ce cas, vous faites probablement une branche "1.1" et une balise "1.1beta1". Maintenant, travailler 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 - version 1.0.2 à venir
  • branches / 1.1 - version 1.1.0 à venir
  • tags / 1.0.0 - 1.0.0 version
  • tags / 1.0.1 - 1.0.1 version de publication
  • tags / 1.1beta1 - 1.1 beta 1 version

Une fois que vous avez sorti la finale 1.1, vous faites une balise "1.1" de la branche "1.1".

Vous pouvez également continuer à conserver 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 est que pour chaque version principale du logiciel que vous gérez, vous avez 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 publication) et que vous travaillez sur une nouvelle entité 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 caractéristique expérimentale

L'idée de cela est quand vous travaillez sur quelque chose de perturbateur (qui pourrait retarder ou interférer avec d'autres personnes de faire leur travail), quelque chose d'expérimental (qui peut même ne pas entrer), ou peut-être juste quelque chose qui prend du temps (et vous avez peur si vous tenez une version 1.2 lorsque vous êtes prêt pour la branche 1.2 à partir du tronc), vous pouvez le faire isolément dans une branche. Généralement, vous le tenez à jour avec le tronc en y intégrant des modifications, ce qui facilite la réintégration (fusionner vers le tronc) lorsque vous avez terminé.


Notez également que le schéma de gestion des versions que j'ai utilisé ici en est un parmi tant d'autres. Certaines équipes feraient 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 côté, versionnage sémantique est un bon guide sur la façon de faire les numéros de version).


536
2017-09-20 19:00



En plus de ce que Nick a dit, vous pouvez en savoir plus à Lignes en continu: modèles de branchement pour le développement de logiciels parallèles

enter image description here

Dans cette figure main est le coffre, rel1-maint est une branche et 1.0 est une étiquette


92
2017-08-19 13:58



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

  • Tronc est une branche principale conseillé par Subversion, mais vous n'êtes pas obligé de le créer. Vous pouvez l'appeler 'main' ou 'releases', ou n'en pas avoir du tout!

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

    • un objet 'myProject_dev' ou 'myProject_Merge'
    • un périmètre de version 'myProjetc1.0_dev' ou myProject2.3_Merge 'ou' myProject6..2_Patch1 '...
  • Marque est un instantané de fichiers afin de revenir facilement à cet état. Le problème est que tag et branche est le même 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 quoi que ce soit, mais de créer de nouvelles copies dans la zone de tags.

Une étiquette est définitive. Son contenu ne devrait jamais changer. JAMAIS. Déjà. Vous avez oublié une ligne dans la note de mise à jour? Créer un nouveau tag Obsolète ou supprime l'ancien.

Maintenant, je lis beaucoup sur "la fusion de tel ou tel dans telle ou telle branche, puis finalement dans la branche du 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 de tronc que vous avoir à fusionner n'importe quoi.

Par convention, la branche 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 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 doit pas nécessairement être fusionné dans «tronc».


73
2017-08-19 13:25



Dans SVN, un tag et une branche sont vraiment similaires.

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

Branche = aussi une tranche définie dans le temps que le développement peut continuer, habituellement utilisé pour les versions majeures comme 1.0, 1.5, 2.0, etc, puis quand vous relâchez vous marquez la branche. Cela vous permet de continuer à prendre en charge une version de production tout en avançant avec des changements de rupture dans le coffre

Tronc= espace de travail de développement, c'est là que tout le développement devrait se produire, puis les modifications sont fusionnées à partir des versions de branches.


36
2017-08-19 13:27



Ils n'ont pas vraiment de signification formelle. Un dossier est un dossier à 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 la branche est l'endroit où vous pouvez créer, eh bien, les branches, qui sont difficiles à expliquer dans un court message.

  • 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 pourraient ne pas aller n'importe où, ou peut-être pour la prochaine version, que vous allez fusionner plus tard dans le coffre quand il devient stable.

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

Mais comme je l'ai dit, SVN, un dossier est un dossier. branch, trunk et tag sont juste une convention.

J'utilise le mot 'copier' libéralement. SVN ne fait pas réellement des copies complètes des choses dans le dépôt.


28
2017-08-19 13:37



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

le branches sont habituellement utilisés pour faire quelque chose à partir du tronc (ou d'une autre ligne de développement) qui autrement Pause 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 est dérivé. Par exemple, un programmeur peut essayer une optimisation sur quelque chose dans une branche et ne fusionner dans la ligne de développement qu'une fois l'optimisation satisfaisante.

le Mots clés sont des instantanés du référentiel à un moment donné. Aucun développement ne devrait se produire 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 sur les dépôts:

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


12
2018-06-30 11:50



En ce qui concerne le développement de logiciels, il n'y a pas de connaissances cohérentes sur quoi que ce soit, tout le monde semble l'avoir à sa manière, 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 de troncs contient le corpus de travail le plus récent, approuvé et fusionné. Contrairement à ce que beaucoup ont avoué, ma malle est uniquement pour 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 tronc semble prêt à être libéré, il est étiqueté et libéré.

branches - Le répertoire des branches contient des expériences et des travaux en cours. Travailler sous une branche reste 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 un itération-5 branche pour un cinquième cycle de développement sur le produit, peut-être un prototype-9 branche pour un neuvième cycle d'expérimentation, et ainsi de suite.

Mots clés - Le répertoire des balises contient des instantanés de branches approuvées et de versions de jonctions. Chaque fois qu'une succursale est autorisée à fusionner dans le circuit ou qu'une version du réseau est validée, un cliché de la version approuvée de la succursale ou du tronçon est effectué sous les balises.

Je suppose qu'avec des balises, je peux sauter dans le temps pour pointer l'intérêt assez facilement.


10
2017-08-19 13:28



Le répertoire de tronc est le répertoire avec lequel vous êtes le plus familier car il est utilisé pour contenir les modifications les plus récentes. Votre base de code principale devrait être dans le coffre.

Le répertoire des succursales sert à tenir 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 à ces révisions et "1.1" pour être ces fichiers à 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 tags, voir Chapitre 4. Branchement et fusion (dans Contrôle de version avec Subversion).


8
2017-11-17 20:39



Une des raisons pour lesquelles tout le monde a une définition légèrement différente est que Subversion implémente zéro support pour les branches et les tags. Subversion dit essentiellement: Nous avons examiné complet branches et des étiquettes dans d'autres systèmes et ne les a pas trouvés utiles, nous n'avons donc rien mis en œuvre. Faites simplement une copie dans un nouveau répertoire avec un nom convention au lieu. Alors bien sûr, tout le monde est libre d'avoir des conventions légèrement différentes. Pour comprendre la différence entre un réal tag et une simple copie + convention de nommage voir l'entrée de Wikipedia Tags et branches Subversion.


8
2017-07-26 08:56