Comment placez-vous différentes versions de votre bibliothèque sous contrôle de version? Utilisez-vous des tags? Ou des succursales? Ou une autre méthode?


24

J'ai récemment commencé à mettre mon code sous contrôle de version (dans le laboratoire, je travaille, sous SVN, et mes propres codes dans github (évidemment avec git)). Avant d'utiliser le contrôle de version, je faisais quelque chose comme ça. J'avais un dossier avec le nom de la bibliothèque, à l'intérieur de nombreux dossiers avec le numéro de version. Chaque fois que je voulais commencer à travailler sur une version plus récente, je faisais une copie de la dernière version, je changeais le nom pour la nouvelle version et je commençais à l'implémenter.

Cela semble cependant redondant lorsque le dossier est placé sous contrôle de version. En dehors de la redondance, si quelqu'un veut obtenir la dernière version, il téléchargera toutes les versions s'il vient de imports / clones.

Maintenant, je vois de nombreuses façons de le faire avec le contrôle de version, mais comme je suis nouveau dans ce domaine, je ne sais pas lequel serait plus facile à maintenir.

Méthode 1: utiliser des balises

Si je comprenais bien les balises, vous auriez votre branche principale, vous valideriez les modifications que vous auriez et les étiquetteriez avec une version. Ensuite, lorsque vous souhaitez en obtenir une copie de travail, vous obtenez celle avec une certaine balise. (Corrige moi si je me trompe)

Méthode 2: versions de branchement

Dans cette méthode, la branche principale serait la branche de développement. De temps en temps, une version stable est v1.2.0créée (disons ), vous créez une branche pour cette version et ne vous y engagez jamais. De cette façon, si vous souhaitez télécharger une certaine version, vous obtenez le code de cette branche. Bien que je vous ai dit de ne jamais vous y engager, il peut être possible de corriger des bogues et de vous engager dans la branche d'une ancienne version pour garder l'ancienne version en cours d'exécution. Par exemple, si la version actuelle est v2.0, mais qu'il y a des gens qui veulent l'utiliser v1.2, vous pouvez obtenir une autre branche v1.2, à savoir v1.2.1et valider les corrections de bogues, ou simplement conserver la version identique à v1.2et simplement valider les corrections de bogues.

Ainsi, les branches ressembleraient à ceci:

                  v1.2.1  v1.2.2
                 /       /
 v1.0.0   v1.2.0---------     v2.0.0
/        /                   /
-------------------------------------- dev

De cette façon, vous avez des branches pour chaque mise à jour de version mineure. (Notez que dans le graphique ci-dessus, v1.2.1 et v1.2.2 ou créés après la sortie de la v2.0.0, ils ne faisaient donc pas partie du développement entre la v1.2.0 et la v2.0.0. Considérez-le comme un support pour les anciennes versions)

Méthode 3: développement de branchement

Cette méthode est l'opposé de la précédente. La branche principale serait la dernière version stable. Chaque fois que vous travaillez sur une nouvelle version, vous créez une branche (pour le développement), travaillez sur votre code et quand il est stable, fusionnez-le avec la branche principale.

Dans ce cas, les branches ressembleraient à ceci:

 ________  ____  ________________  _____ dev
/        \/    \/                \/
---------------------------------- latest_version

Probablement celui-ci doit être fait en conjonction avec des balises non?

La question!

Quoi qu'il en soit, ma question est la suivante: d'après votre expérience, laquelle de ces méthodes s'avère plus pratique? Existe-t-il une meilleure méthode connue (que je n'ai peut-être pas compris moi-même)? Comment ces choses sont-elles couramment accomplies?

Réponses:


17

Les balises et les branches ne sont pas mutuelles, vous pouvez (et l'OMI devrait généralement) les utiliser toutes les deux. Les balises sont là pour marquer les étapes du développement. Par exemple , vous ouvrez une branche pour la version 1.2 de votre produit, et vous marquez v1.2 Beta, RC1, RC2, Final(puis, si nécessaire , SP1etc.) avec des étiquettes sur la même branche.

Personnellement, je préfère la méthode 2 comme approche par défaut (bien que j'essaie d'éviter plusieurs niveaux de branches, pour garder la vie aussi simple que possible). La méthode 1 ne fonctionnera tout simplement pas dans la vie réelle - les balises ne suffisent pas, vous avez besoin de branches. Et la méthode 3 est inflexible en ce qu'elle n'a qu'une seule version stable à tout moment, donc (sauf si vous la combinez avec la méthode 2), vous ne pouvez pas maintenir plusieurs versions (les plus récentes et les plus anciennes) en parallèle. Ceci est requis pour presque tous les projets dans la vie réelle - pendant que vous travaillez sur la version 2, vous devriez toujours pouvoir publier des correctifs / mises à niveau pour la v1.9, et souvent même des versions antérieures. Cela dépend beaucoup du type d'application bien sûr. Nous développons une application web, il n'y a donc qu'une seule version de production à un moment donné, mais nous jonglons souvent avec 3 versions différentes (une en production, l'un est en préparation de l'UAT pour le déploiement, l'autre est la dernière version sur le tronc). Cela peut devenir beaucoup plus complexe pour une application de bureau / client avec plusieurs versions plus anciennes utilisées - et maintenues - en parallèle.


Eh bien, comme je l'ai dit, la méthode 3 pourrait être combinée avec des balises, vous avez donc des balises pour les validations stables. Je ne suis pas sûr, si j'ai les bonnes balises, mais vous balisez une validation et vous pouvez alors obtenir le référentiel avec la validation qui a cette balise? Si c'est le cas, vous avez de nombreuses versions stables, mais elles sont dans la même branche (sous des balises différentes)
Shahbaz

@Shahbaz, oui, mais le fait est que les versions balisées sont en lecture seule, vous ne pouvez pas y apporter de modifications. Cela signifie que vous ne pouvez pas corriger les bogues dans les anciennes versions lors du développement de nouvelles fonctionnalités sur le tronc.
Péter Török

N'oubliez pas, vous ne pouvez utiliser que des balises et si vous devez revenir en arrière et corriger quelque chose pour une ancienne version, vous pouvez convertir cette balise en une branche lorsque vous en avez besoin.
Chloe

6

J'avais un dossier avec le nom de la bibliothèque, à l'intérieur de nombreux dossiers avec le numéro de version.

C'est effectivement, comme vous le constatez, une mauvaise approche, puisque vous avez déjà le contrôle de version pour ... contrôler les versions.

Maintenant, les différentes techniques que vous énumérez semblent toutes aussi bonnes. Vous pouvez lire un article très détaillé, Source Control Done Right , qui comprend des informations sur les balises et les branches.


Oui, la première méthode était ce que je faisais avant de placer mon code sous contrôle de version. Je vais lire votre lien et vous le faire savoir
Shahbaz

Le lien était super. J'ai le sentiment que la méthode 2 est meilleure (au moins pour moi, qui suis essentiellement le seul développeur des bibliothèques)
Shahbaz

3

Les trois méthodes ne s'excluent pas mutuellement et vous devez combiner les trois pour tirer le meilleur parti de votre contrôle de version.

Pour ma part, j'utiliserais une combinaison des méthodes 1 et 3 par défaut, c'est-à-dire que je développerais dans une branche de fonctionnalité ou de développement jusqu'à ce qu'une fonctionnalité soit prête pour la production, puis que je fusionne à nouveau dans le tronc. De cette façon, trunk représente toujours l'état actuel du développement stable et à utiliser et peut être lié en toute sécurité par svn: external projects. Lorsque vous publiez une version, étiquetez-la.

Je ne branche que sur demande, c'est-à-dire lorsque les anciennes versions de votre bibliothèque ont un bogue qui doit être corrigé. Vous pouvez facilement créer cette branche à partir de la balise de la version cassée. En ne ramifiant pas inutilement, vous gardez un nombre de branches bas et avez un aperçu rapide sur les bords de saignement qui doivent être maintenus (tronc et toutes les branches).


2

J'utiliserais la méthode 2 . Je l'ai utilisé et j'ai trouvé que c'était un moyen efficace de gérer et de maintenir plusieurs versions tout en permettant au développement actuel d'avancer. Vous pouvez également utiliser des balises conjointement avec cette méthode si vous en avez besoin.

Voir ma réponse ici pour plus d'informations sur l'utilisation de la branche pour maintenir plusieurs versions.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.