Comment utiliser SVN, Branch? Étiquette? Tronc?
J'étais en train de googler un peu et je ne pouvais pas trouver un bon guide "débutant" vers SVN , pas dans le sens de "comment utiliser les commandes " plutôt; Comment contrôler mon code source?
Ce que je voudrais éclaircir est les sujets suivants:
- À quelle fréquence vous engagez-vous? Aussi souvent que l'on presserait Ctrl + s?
- Qu'est-ce qu'une branche et qu'est-ce qu'une balise et comment les contrôlez-vous?
- Qu'est-ce qui entre dans le SVN? Seulement le code source ou partagez-vous d’autres fichiers ici aussi? (Fichiers non pris en compte non considérés ..)
Je ne sais pas du tout quelle branche et quelle balise, je ne connais donc pas le but recherché, mais je suppose que vous téléchargez des éléments dans le coffre et que, lorsque vous effectuez une construction majeure, vous les déplacez vers la branche? Alors, qu'est-ce qui est considéré comme une construction majeure dans ce cas?
Le livre de Subversion est une excellente source d’informations sur les stratégies de mise en page, de branchement et de marquage de votre référentiel.
Voir également:
Continuez-vous le développement dans une branche ou dans le coffre
Je me suis posé les mêmes questions lorsque nous avons implémenté Subversion ici - environ 20 développeurs répartis sur 4 à 6 projets. Je n'ai trouvé aucune bonne source avec '' la réponse ''. Voici quelques extraits de l'évolution de notre réponse au cours des 3 dernières années:
- commettre aussi souvent que nécessaire; notre règle de base est de valider chaque fois que vous avez effectué suffisamment de travail pour que ce soit un problème de devoir le refaire si les modifications sont perdues; parfois je commets toutes les 15 minutes environ, d'autres fois, il peut s'agir de jours (oui, parfois cela me prend un jour pour écrire une ligne de code)
- nous utilisons des branches, comme l’a suggéré l’une de vos réponses précédentes, pour différents chemins de développement; À l’heure actuelle, l’un de nos programmes compte 3 branches actives: 1 pour le développement principal, 1 pour l’effort non encore achevé de paralléliser le programme et 1 pour l’effort de le réviser pour utiliser des fichiers d’entrée et de sortie XML;
- nous utilisons rarement des étiquettes, bien que nous estimions devoir les utiliser pour identifier les versions entrant en production;
Pensez au développement suivant un seul chemin. À un moment ou à un stade de développement, le marketing décide de publier la première version du produit. Vous plantez donc un indicateur dans le chemin intitulé "1" (ou "1.0" ou ce que vous avez). À un autre moment, quelque brillant spark décide de paralléliser le programme, mais décide que cela prendra des semaines et que les gens veulent continuer à suivre la voie principale entre-temps. Vous construisez donc une fourchette dans le chemin et différentes personnes errent dans les différentes fourches.
Les drapeaux sur la route sont appelés "tags", et les fourches sur la route sont l'endroit où les "branches" se divisent. De temps en temps aussi, les branches reviennent ensemble.
- nous mettons tout le matériel nécessaire pour construire un exécutable (ou un système) dans le référentiel; Cela signifie au moins le code source et créer un fichier (ou des fichiers de projet pour Visual Studio). Mais lorsque nous avons des icônes, des fichiers de configuration et tout le reste, cela entre dans le référentiel. Certains documents se retrouvent dans le repo; certes, toute documentation, telle que des fichiers d’aide pouvant faire partie intégrante du programme, est utile, et c’est un endroit utile pour mettre la documentation destinée aux développeurs.
Nous avons même inclus des exécutables Windows pour nos versions de production, afin de fournir un emplacement unique aux personnes à la recherche de logiciels - nos versions de Linux sont envoyées sur un serveur, elles n'ont donc pas besoin d'être stockées.
- nous n'exigeons pas que le référentiel soit à tout moment capable de fournir une version la plus récente qui construit et exécute; certains projets fonctionnent de cette façon, d'autres pas; la décision incombe au gestionnaire de projet et dépend de nombreux facteurs, mais j'estime qu'elle échoue lors de modifications majeures d'un programme.
* How often do you commit? As often as one would press ctrl + s?
Aussi souvent que possible. Le code n'existe que s'il est sous contrôle de code source :)
Les commits fréquents (par la suite, de plus petites séries de modifications) vous permettent d’intégrer facilement vos modifications et d’augmenter les chances de ne pas casser quelque chose.
D'autres personnes ont noté que vous devriez vous engager lorsque vous avez un élément de code fonctionnel, mais je trouve utile de le faire un peu plus souvent. Quelques fois, j'ai remarqué que j'utilisais le contrôle de source en tant que mécanisme rapide d'annulation/restauration.
Lorsque je travaille sur ma propre branche, je préfère m'engager autant que possible (littéralement aussi souvent que j'appuie sur ctrl + s).
* What is a Branch and what is a Tag and how do you control them?
Lire livre SVN - c’est un endroit par lequel vous devriez commencer lorsque vous apprenez le SVN:
* What goes into the SVN?
La documentation, les petits fichiers binaires requis pour la construction et d'autres éléments ayant une certaine valeur vont au contrôle de source.
Voici quelques ressources sur la fréquence de validation, les messages de validation, la structure de projet, les éléments à mettre sous contrôle de source et d'autres instructions générales:
- Meilleures pratiques de contrôle de version (mon propre blog)
- Check in Early, Check in Souvent (Coding Horror) (les commentaires ici contiennent beaucoup de bons conseils)
- politique de commit de KDE
Ces questions sur le dépassement de pile contiennent également des informations utiles pouvant vous intéresser:
- Organisation de la base de code source lors du mélange de deux langages ou plus (comme Java et C++))
- Suggestions pour un bon message de commit: format/guideline?
- À quelle fréquence engager les modifications dans le contrôle de source?
- Apprendre à contrôler les versions et bien apprendre
En ce qui concerne les concepts de base de Subversion tels que la création de branches et le marquage, je pense que cela est très bien expliqué dans le livre de Subversion .
Comme vous vous en rendrez probablement compte après avoir lu un peu plus sur le sujet, les opinions des gens sur les meilleures pratiques dans ce domaine sont souvent divergentes et parfois contradictoires. Je pense que la meilleure option pour vous est de lire ce que font les autres et de choisir les directives et les pratiques qui vous semblent les plus utiles.
Je ne pense pas que ce soit une bonne idée d'adopter une pratique si vous ne comprenez pas son but ou si vous n'acceptez pas la raison qui la sous-tend. Ne suivez donc aucun conseil à l’aveuglette, mais décidez vous-même de ce qui, à votre avis, fonctionnera le mieux pour vous. En outre, expérimenter différentes façons de faire est un bon moyen d'apprendre et de découvrir comment vous aimez le mieux travailler. Un bon exemple de ceci est la façon dont vous structurez le référentiel. Il n'y a pas de bonne ou de mauvaise façon de le faire, et il est souvent difficile de savoir quelle voie vous préférez avant de les avoir réellement essayés.
La fréquence de validation dépend de votre style de gestion de projet. Beaucoup de gens s'abstiennent de s'engager si ça casse la construction (ou la fonctionnalité).
Les branches peuvent être utilisées de deux manières différentes: 1) une branche active pour le développement (et le tronc reste stable), ou 2) des branches pour les chemins de développement alternatifs.
Les étiquettes sont généralement utilisées pour identifier les versions, afin qu'elles ne se perdent pas dans le mix. La définition de "libération" est à vous.
Je pense que le problème principal est que l'image mentale du contrôle de source est confuse. Nous avons généralement des troncs et des branches, mais nous obtenons ensuite des idées sans rapport avec les balises/versions ou quelque chose de ce genre.
Si vous utilisez l'idée d'un arbre plus complètement, cela devient plus clair, du moins pour moi.
Nous obtenons le tronc -> formes branches -> produire des fruits (étiquettes/communiqués).
L'idée est que vous développez le projet à partir d'un tronc, ce qui crée ensuite des branches une fois que le tronc est suffisamment stable pour contenir la branche. Ensuite, lorsque la branche a produit un fruit, vous l’arrachez et vous le relâchez comme une étiquette.
Les tags sont essentiellement des livrables. Alors que le tronc et les branches les produisent.
Comme d'autres l'ont déjà dit, le SVN Book est le meilleur endroit pour commencer et une excellente référence une fois que vous avez acquis la maîtrise de la mer. Maintenant, à vos questions ...
À quelle fréquence vous engagez-vous? Aussi souvent qu’on presserait ctrl + s?
Souvent, mais pas aussi souvent que vous appuyez sur ctrl + s. C'est une question de goût personnel et/ou de politique d'équipe. Personnellement, je dirais commettre lorsque vous complétez un code fonctionnel, même le plus petit.
Qu'est-ce qu'une branche et une balise et comment les contrôlez-vous?
Premièrement, le tronc est l'endroit où vous effectuez votre développement actif. C'est la ligne principale de votre code. Une branche est un écart par rapport à la ligne principale. Cela pourrait être une déviation majeure, comme une version précédente, ou juste un Tweak mineur que vous voulez essayer. Une balise est un instantané de votre code. C'est un moyen d'attacher une étiquette ou un signet à une révision particulière.
Il est également intéressant de noter que dans Subversion, le tronc, les branches et les tags ne sont que des conventions. Rien ne vous empêche de travailler dans les balises ou d'avoir des branches qui constituent votre ligne principale, ou d'ignorer le schéma balise-branche-tronc dans son ensemble. Mais, à moins que vous n'ayez une très bonne raison, il est préférable de respecter les conventions.
Que contient le SVN? Seulement le code source ou partagez-vous d’autres fichiers ici?
Aussi un choix personnel ou d'équipe. Je préfère garder tout ce qui concerne la construction dans mon référentiel. Cela inclut les fichiers de configuration, les scripts de construction, les fichiers multimédias associés, la documentation, etc. Vous devez pas archiver les fichiers devant être différents sur la machine de chaque développeur. Vous n'avez pas besoin non plus d'archiver les sous-produits de votre code. Je pense surtout aux dossiers de construction, aux fichiers objets, etc.
Eric Sink, paru sur le SO podcast n ° 36 en janvier 2009), a écrit une excellente série d'articles sous le titre Guide du code source .
(Eric est le fondateur de SourceGear qui commercialise une version compatible de Plug-in de SourceSafe, mais sans l’horreur.)
Juste pour ajouter un autre ensemble de réponses:
- Je commets chaque fois que je termine un travail. Parfois, c'est une toute petite correction qui ne changeait qu'une ligne et me prenait 2 minutes; d'autres fois, cela fait deux semaines de sueur. En outre, en règle générale, vous ne commettez rien qui brise la construction. Ainsi, si cela vous a pris beaucoup de temps, prenez la dernière version avant de vous engager et vérifiez si vos modifications cassent la construction. Bien sûr, si je reste longtemps sans m'engager, cela me met mal à l'aise car je ne veux pas perdre ce travail. Dans TFS, j'utilise cette belle chose comme "étagère" pour cela. Dans SVN, vous devrez contourner le problème autrement. Peut-être créer votre propre branche ou sauvegarder ces fichiers manuellement sur une autre machine.
- Les branches sont des copies de tout votre projet. La meilleure illustration de leur utilisation est peut-être le contrôle de version des produits. Imaginez que vous travaillez sur un grand projet (par exemple, le noyau Linux). Après des mois de sueur, vous êtes enfin arrivé à la version 1.0 que vous publiez. Après cela, vous commencez à travailler sur la version 2.0 de votre produit, qui sera bien meilleure. Mais entre temps, beaucoup de gens utilisent la version 1.0. Et ces personnes trouvent des bugs que vous devez corriger. Désormais, vous ne pouvez pas corriger le bogue dans la version 2.0 à venir et l’envoyer aux clients - ce n’est pas prêt du tout. Au lieu de cela, vous devez extraire une ancienne copie de la source 1.0, corriger le bogue et l’envoyer aux gens. C'est à quoi servent les branches. Lorsque vous avez publié la version 1.0, vous avez créé une branche dans SVN qui a copié le code source à ce stade. Cette branche s'appelait "1.0". Vous avez ensuite continué à travailler sur la version suivante dans votre copie source principale, mais la copie 1.0 est restée telle quelle au moment de la publication. Et vous pouvez continuer à corriger les bugs ici. Les balises ne sont que des noms associés à des révisions spécifiques pour en faciliter l'utilisation. Vous pourriez dire "Révision 2342 du code source", mais il est plus facile de s'y référer en tant que "Première révision stable". :)
- D'habitude, je mets tout dans le contrôle de code qui concerne directement la programmation. Par exemple, depuis que je crée des pages Web, je mets également des images et des fichiers CSS dans le contrôle de source, sans parler des fichiers de configuration, etc.
D'autres ont déclaré que cela dépend de votre style.
La grande question pour vous est de savoir combien de fois vous "intégrez" votre logiciel. Le développement piloté par les tests, Agile et Scrum (et bien d’autres encore) reposent sur de petits changements et une intégration continue. Ils prêchent que de petits changements sont apportés, tout le monde trouve les pauses et les répare tout le temps.
Cependant, sur un projet plus important (gouvernement, défense, 100 000 $ + LOC), vous ne pouvez tout simplement pas utiliser l'intégration continue car ce n'est pas possible. Dans ces situations, il peut être préférable d’utiliser les branches pour effectuer de nombreux petits engagements, mais ne ramener dans le coffre QUE ce qui fonctionnera et qui est prêt à être intégré à la construction.
Un inconvénient avec les branches est cependant que si elles ne sont pas gérées correctement, cela peut être un cauchemar dans votre référentiel de mettre du travail dans le coffre, car tout le monde se développe à partir de points différents sur le coffre (ce qui est d'ailleurs l'un des arguments les plus importants pour Intégration continue).
Il n’ya pas de réponse définitive à cette question, le meilleur moyen est de travailler avec votre équipe pour trouver la meilleure solution de compromis.
Version Control with Subversion est le guide pour les débutants et les vieux.
Je ne pense pas que vous puissiez utiliser efficacement Subversion sans lire au moins les premiers chapitres de ce document.
Pour commettre, j'utilise les stratégies suivantes:
commettre aussi souvent que possible.
Chaque changement de fonctionnalité/correction de bogue devrait avoir son propre commit (ne validez pas plusieurs fichiers à la fois car cela rendrait l'historique de ce fichier incertain - par exemple, si je change un module de journalisation et un module d'interface graphique indépendamment et que je les valide tous les deux à la fois, les deux modifications seront visibles dans les deux historiques de fichiers, ce qui rend la lecture de l'historique des fichiers difficile),
ne cassez pas la construction sur aucun commit - il devrait être possible de récupérer n'importe quelle version du référentiel et de le construire.
Tous les fichiers nécessaires à la création et à l'exécution de l'application doivent être en SVN. Les fichiers de test et autres ne doivent pas, sauf s’ils font partie des tests unitaires.
La politique de notre travail est la suivante (équipe de plusieurs développeurs travaillant sur un cadre orienté objet):
Mise à jour de SVN tous les jours pour connaître les modifications de la veille
Engagez-vous quotidiennement afin que, si vous êtes malade ou absent le lendemain, quelqu'un d'autre puisse facilement prendre le relais de l'endroit où vous l'avez laissé.
Ne commettez pas de code qui rompt n'importe quoi, car cela affectera les autres développeurs.
Travaillez sur de petits morceaux et engagez-vous quotidiennement AVEC DES COMMENTAIRES SIGNIFICATIFS!
En tant qu'équipe: conservez une branche Développement, puis déplacez le code de pré-version (pour l'AQ) dans une branche Production. Cette branche ne devrait jamais avoir de code pleinement fonctionnel.
Beaucoup de bons commentaires ici, mais quelque chose qui n'a pas été mentionné est des messages de validation. Ceux-ci devraient être obligatoires et significatifs. Surtout avec la ramification/fusion. Cela vous permettra de garder une trace des modifications pertinentes pour les caractéristiques des bogues.
par exemple svn commit . -m 'bug #201 fixed y2k bug in code' dira à tous ceux qui regardent dans l’historique à quoi servait cette révision.
Certains systèmes de suivi de bogues (par exemple, trac) peuvent rechercher ces messages dans le référentiel et les associer aux tickets. Ce qui facilite le travail sur les modifications associées à chaque ticket.
TortoiseSVN Manuel de TSVN est basé sur livre de Subversion , mais disponible dans beaucoup plus de langues.
Je pense qu'il y a deux façons de commettre la fréquence:
- S'engager très souvent, pour chaque méthode implémentée, une petite partie du code, etc.
- N'engagez que des parties de code complètes, telles que des modules, etc.
Je préfère le premier car l'utilisation du système de contrôle de code source est très utile non seulement pour les projets ou les entreprises, mais avant tout pour le développeur. Pour moi, la meilleure fonctionnalité consiste à restaurer tout le code tout en recherchant la meilleure implémentation de tâche assignée.