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.
- 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 étiquette "1.0.0". Maintenant, le travail sur ce qui sera éventuellement la 1.1 continue dans le tronc.
- trunk/ - version de développement, bientôt 1.1
- branches/1.0 - version de la version 1.0.0
- tags/1.0.0 - version de la version 1.0.0
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.
- trunk/ - version de développement, bientôt 1.1
- branches/1.0 - prochaine version 1.0.1
- tags/1.0.0 - version de la 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. 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.
- trunk/ - version de développement, bientôt 1.1
- branches/1.0 - prochaine version 1.0.2
- tags/1.0.0 - version de la version 1.0.0
- tags/1.0.1 - version de la version 1.0.1
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".
- 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 - version de la version 1.0.0
- tags/1.0.1 - version de la version 1.0.1
- tags/1.1beta1 - version de la version 1.1 beta 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.
- trunk/ - version de développement, bientôt 1.2
- branches/1.1 - prochaine version 1.1.0
- branches/ui-rewrite - branche de fonctionnalité expérimentale
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).
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