Est-ce une bonne pratique d'utiliser des branches pour gérer différentes éditions du même logiciel?
Nous avons un produit qui a plusieurs éditions différentes. Les différences sont mineures: différentes chaînes ici et là, très peu de logique supplémentaire dans l'une, très peu de différence de logique dans l'autre. Lors du développement du logiciel, la plupart des modifications doivent être ajoutées à chaque édition; cependant, il y en a quelques-uns qui ne le font pas et quelques-uns qui doivent différer. Est-ce une utilisation valide des branches si j'ai des branches release-editionA et release-editionB (..etc)? Y a-t-il des problèmes? Bonnes pratiques?
Mise à jour: Merci pour la perspicacité de chacun, beaucoup de bonnes réponses ici. Le consensus général semble être que c'est une mauvaise idée d'utiliser des branches à cette fin. Pour tous ceux qui se demandent, ma dernière solution au problème est d'externaliser les chaînes en tant que configuration et d'externaliser la logique différente en tant que plugins ou scripts.
Cela dépend de l'ampleur du changement, mais je ne considère pas que ce soit une bonne pratique pour les différences que vous avez décrites.
En règle générale, vous souhaitez qu'une branche Git soit quelque chose qui sera fusionnée à l'avenir ou stockée en lecture seule pour référence. Les branches Git qui coexistent indéfiniment signifient du travail pour tout le monde: les changements doivent être propagés et fusionnés, les conflits résolus, tout le plaisir. Si rien d'autre, chaque développeur doit se rappeler de pousser les modifications à cinq référentiels au lieu d'un.
Si vous avez de petits changements, tout l'effort de fusion et de maintien de branche semble exagéré par rapport au problème. Utilisez votre préprocesseur ou votre système de construction pour différencier les versions. Est-ce qu'un simple #ifdef faire l'affaire? Alors ne résolvez pas les problèmes avec git, c'est exagéré.
Ce n'est pas vraiment à ça que servent les succursales. Les branches sont censées être des chemins latéraux à court et à moyen terme vers votre ligne de développement, et non des versions parallèles à long terme du même code.
Je mettrais toutes les différentes versions dans la même branche, avec des sous-répertoires pour les parties différentes entre les éditions, et configurerais votre processus de construction (vous avez une construction automatisée, non?) Afin qu'il puisse sortir l'une ou l'autre édition à la demande (ou tous à la fois).
Après tout, vous voulez garder une "source unique de vérité"; avec les branches, vous dupliquerez du code, mais pas tout, et certaines fusions briseraient en fait votre configuration.
Une solution - comme certains l'ont souligné - consiste à configurer le système de génération pour prendre en charge différentes éditions.
J'envisagerais également de l'implémenter en tant que bascule de fonctionnalité et d'utiliser un fichier de configuration. Moins vous avez à construire, mieux c'est.
Je pense que c'est une bonne idée à condition que vous ne puissiez pas le faire dans une seule branche sans trop regrouper le code.
Je préférerais pouvoir le conserver dans une seule branche et utiliser des fichiers localisés et de configuration, surtout si vous dites que les différences sont mineures.
Une autre façon pourrait être différentes versions, par exemple votre fichier de version contient différents fichiers pour différents clients, mais je peux également voir l'outil de génération vérifier différentes branches. Lorsque vous utilisez git, je dirais qu'il n'y a pas de vrais problèmes. Une stratégie de branchement pourrait être de développer sur différentes branches pour différentes tâches, de s'enregistrer dans la branche principale et de fusionner du maître à l'éditionX et Y.
Cela ressemble plus à un travail pour différentes configurations de construction. réponse de thiton va dans cette direction mais je le prendrais beaucoup plus loin que #ifdef:
Utilisez différentes cibles de génération pour créer différentes éditions du logiciel. Les objectifs peuvent différer selon
- la configuration qu'ils incluent,
- l'objet ou les fichiers source qu'ils incluent, ou
- le prétraitement du code source.
Ce prétraitement peut évidemment inclure le préprocesseur C classique mais il pourrait également impliquer l'utilisation d'un préprocesseur personnalisé, d'un moteur de template pour construire des vues personnalisées,…
De cette façon, vous évitez d'avoir à pousser activement chaque modification vers plusieurs branches, ce qui viole DRY (bien sûr, cela peut aussi être automatisé, mais je ne vois pas l'avantage).
Je n'utiliserais des branches que pour des changements importants, sinon vous finissez par ajouter chaque petit changement à de nombreuses branches, ce qui n'est pas amusant du tout et est très sujet aux erreurs, surtout si vous travaillez avec plus de personnes.
Si vous les publiez tous en tant que produits différents, il est recommandé d'avoir plusieurs succursales. Sinon, il est toujours recommandé d'utiliser quelque chose comme un tronc ou une branche principale.
De plus, je pense que cela dépendra du processus de développement que vous avez, en particulier du déploiement. Si vous avez un processus qui autorise le déploiement d'une seule branche en production et que les branches sont traitées comme des "builds incrémentiels", la version B ne peut pas être déployée en production à moins que la version A n'ait été déployée en premier, étant donné que toutes les modifications de A sont déjà en B, alors avoir plusieurs branches est la voie à suivre. Cela fonctionnera si vous avez des équipes dispersées dans le monde entier et que vous avez généralement des modifications ordonnées par priorité.