Remarque: Ma question se concentre sur mon problème spécifique (qui concerne Liferay) mais j'espère que cela peut être utile pour quiconque a besoin de maintenir différentes versions d'un même projet sur git.

Je travaille sur une entreprise qui écrit de nombreux plugins pour Liferay Portal . Ces plugins (portlets, thèmes, etc.) sont généralement réutilisables et, bien sûr, doivent être mis à jour pour les nouvelles versions du portail.

Cependant, il est habituel de devoir migrer, disons, un portlet vers une nouvelle version de Liferay et de conserver sa version précédente. De plus, nous devons fréquemment créer des personnalisations très spécifiques pour certains clients, ce qui n'a pas de sens d'être ajouté à la "version principale".

Ces conditions compliquent notre travail mais, heureusement, nous pouvons supposer quelques simplifications. Par exemple, les plugins sont fréquemment mis à jour par un seul programmeur à la fois. Il est très rare que deux ou plusieurs fonctionnalités soient ajoutées à un plugin en même temps.

Maintenant, nous migrons vers Gitorious . Nous essayons de concevoir un modèle de branchement pour un tel scénario.

Mon modele

Ce que j'ai proposé était:

1. Chaque plugin aurait son propre référentiel dans Gitorious à l'intérieur d'un projet. Par exemple, un portlet pour afficher les chatons aurait un kittens-portletréférentiel à l'intérieur du liferay-portletsprojet.
2. Lors de la création d'un nouveau plugin, créez-le dans une branche nommée en fonction de la version de Liferay (par exemple, lf5.2).
3. Chaque fois qu'une mise à jour est faite sur le plug - in, la mise à jour est approuvé et déployé dans la production, étiquette le plug - in avec une version (par exemple lf5.2v1, lf5.2v2etc.) *
4. Chaque fois qu'un plugin doit être porté sur une nouvelle version de Liferay, nous branchons la version la plus récente (créant, par exemple, la branche lf6.0).
5. Une fois en production, le chef de la nouvelle branche recevra un tag tel que lf6.0v1.
6. Chaque fois que nous devons personnaliser un plugin d'une manière spécifique au client, nous créons une branche avec le nom du client (par exemple, nous lf5.2clientcorpcréerions une branche pour notre client "ClientCorp Inc.")

Il s'agit d'un modèle inhabituel: il n'y aurait pas masteret beaucoup de branches non fusionnées. Voici à quoi je suppose qu'un référentiel avec un tel modèle ressemblerait:

Un ami a trouvé ce système plutôt complexe et sujet aux erreurs. Il a suggéré l'excellent et populaire modèle Vincent Driessen , que j'ai trouvé encore plus difficile à gérer et à discipliner. C'est génial (et testé!) Bien sûr mais semble trop complexe à notre situation.

Le modèle de mon ami

Puis il a suggéré un autre modèle: nous aurions un référentiel pour chaque plugin dans une version Liferay (donc nous commencerions à créer un kittens-lf5.2-portletpuis un a kittens-lf6.0-portlet), chacun avec une masterbranche et une developbranche. Le masterserait toujours prêt pour le déploiement. (Ou ce pourrait être l'inverse, masteret stable, comme l'a suggéré Steve Losh ).

C'est très simple, mais je n'ai pas aimé ce système:

1. il pourrait en résulter un grand nombre de référentiels dans un projet, rendant Gitorious difficile à parcourir.
2. Le nom du répertoire du projet est pertinent. Si quelqu'un clone le référentiel dans un répertoire kittens-lf6.0-portletet génère le WAR avec ant (comme d'habitude), le nom du WAR sera kittens-lf6.0-portletégalement. Les anciennes versions de ce portlet (nommées kittens-portletpar exemple) seraient considérées comme des portlets différents (et probablement manquants) dans un portail mis à niveau. Un peu de soin peut l'éviter mais je préférerais l'éviter.
3. Les différentes versions du même plugin seraient maintenues à part. Je brise mon coeur :(
4. kittens-lf6.0-portlet est un nom moche pour un référentiel, je pense.

Je soupçonne que les deux derniers points - qui sont aussi les deux plus subjectifs - sont la principale raison de ma réticence. Néanmoins, les quatre objections sont valables.

OTOH, ma propre proposition me semble étrange et je me demande s'il y a des bugs cachés dessus. OT3rdH git est si puissant et flexible que je pense que je ne devrais avoir aucune honte à explorer ses possibilités.

Alors je demande:

1. Quel serait le meilleur modèle? Ma proposition? Le modèle de mon ami? Le système désormais traditionnel de Vincent Driessen?
2. Quel autre modèle de branchement proposeriez-vous?
3. Si vous pensez que mon modèle est mauvais, pourquoi pensez-vous que oui? J'aimerais savoir quels sont les inconvénients et les angles morts.

* En fait, je préférerais baliser le commit avec une version telle que v1mais apparemment une balise dans git n'est pas portée dans la branche - c'est-à-dire que je ne pouvais pas avoir une v1balise 1 lf5.2et une autre lf6.0- donc je dois branche. Est-ce correct BTW?

Si je lis bien, les branches sont fondamentalement une déviation ponctuelle de votre ligne principale de développement, jamais destinées à être fusionnées dans la ligne principale et les avancées dans la ligne principale ne sont jamais appliquées à ces branches. La seule différence serait que les correctifs de bogues appropriés à la version sur laquelle la branche était basée doivent être appliqués à la branche.

La réponse dépend maintenant de votre flux de travail quotidien, le nombre de développeurs travaillant sur une branche ou le nombre de modifications sont des harengs rouges. Je vois votre besoin principal de vouloir savoir quelles branches obtiennent une mise à jour de correction de bogue à partir d'un changement de branche principale et pour cela, je pense que le référentiel combiné avec les branches sera plus efficace car il est tout en un seul endroit. S'il n'y avait jamais eu besoin de pollinisation croisée, des référentiels séparés feraient appliquer cela, mais ce scénario ne correspond pas à la réalité de votre projet, si je comprends bien.

Le modèle Driessen fonctionnerait bien si votre projet devait fusionner les branches dans la ligne principale de développement, mais vous n'en avez pas besoin. Néanmoins, je pense qu'il est utile de maintenir un concept InDevelopment et StableRelease si vous travaillez sur un produit qui est en direct.

Donc, pour résumer, je pense que votre projet fonctionnerait bien avec votre modèle de branchement plus un tiret de Driessen pour votre ligne principale. Votre kilométrage peut varier; J'ai toujours travaillé avec une branche "en attente de publication" qui se transforme en une branche "en direct" et une "version suivante" distincte qui nécessitent toutes une pollinisation croisée de correctifs et de modifications à divers points, de sorte que ma perception peut être biaisée.

Ce qui me décourage, c'est le fait que chaque portlet possède son propre référentiel (mais votre histoire n'est peut-être pas complète). Personnellement, je créerais un référentiel par projet. Les projets ont souvent plusieurs portlets et sont tous créés dans la même exécution sur la même version de Liferay. Chaque projet peut être un doublon d'un projet existant qui s'appuie sur une version différente de Liferay, mais je ne diviserais un produit que si les différences sont trop importantes. Si une version fonctionne contre Liferay 5.1 et 5.2, je ne diviserais pas le projet. J'utiliserais des scripts ou Maven (ou les deux) pour que tout fonctionne. J'utiliserais un Wiki (ou Trello) pour la gestion de chaque produit et avec quelle version de Liferay il peut être construit.

Soit dit en passant: je suis programmeur Java, spécialiste Maven, spécialiste de la construction et j'ai de l'expérience avec Liferay et d'autres serveurs de portail (IBM WebSphere et Glassfish).

Mais ce n'est que mon 0,02 €.