Utilisation de Gitflow et du contrôle de version sémantique: comment éviter les conflits de numéro de version lors de la fusion?
Je veux utiliser gitflow en combinaison avec le versioning sémantique. Dans gitflow, vous augmentez les numéros de version sur chaque version ou branche de correctif. Cela entraîne inévitablement des conflits de version si un nouveau cycle de développement (avec un nouveau numéro de version) est démarré alors que le processus de publication en cours est toujours en cours.
Disons que 1.0.0 est sur master, et sur develop je démarre la nouvelle version 2.0.0. Maintenant, un correctif de maître se produit (1.0.1). Lors de la fusion du correctif sur la branche de développement, un conflit se produit.
Il y a une question quelque peu similaire ici sur SE @ Stackexchange, avec une différence majeure: parce que mes outils de construction gradle et maven dépendent fortement des numéros de version, je dois les stocker dans mon code et ne peux pas simplement les générer lors de la création d'une version. Et je dois augmenter le numéro de version lors du développement pour un nouveau cycle de publication, sinon les artefacts seront remplacés.
Alors, comment puis-je gérer mes branches et numéros de version afin qu'aucun conflit de fusion ne puisse se produire?
Vous ne pouvez pas raisonnablement éviter ce conflit de fusion. Mais c'est un conflit très mineur et facile à résoudre pendant la fusion - mais assurez-vous que le numéro de version n'est écrit qu'en n fichier source.
Les correctifs sont probablement assez rares pour qu'une résolution manuelle soit suffisante. Cependant, il pourrait être judicieux d'ajouter une sorte de test que le numéro de version correct a été conservé, par ex. un script pour vérifier que le numéro de version dans une validation augmente de façon monotone à partir de toutes les validations parentes. La fusion des versions 1.0.1 et 2.0.0 serait autorisée pour aboutir à> = 2.0.0.
Notez que Git-Flow n'est pas toujours un modèle de branchement applicable. Il est orienté vers des scénarios qui ont des versions claires et peu fréquentes, où vous devrez peut-être prendre en charge les anciennes versions. Cela peut convenir aux applications ou aux bibliothèques standard.
Git-Flow n'est pas un bon choix lorsque vous pouvez mettre à jour tous les déploiements/utilisateurs vers la dernière version, par exemple pour les logiciels internes, SaaS ou les applications Web/mobiles. Ensuite, un modèle de branchement différent sans branches de version pourrait être plus approprié. Cela implique que votre branche de développement est toujours dans un état libérable, ce qui signifie que toutes les fonctionnalités qui ont été fusionnées sont prêtes à être publiées OR sont protégées par une bascule de fonctionnalité. Un correctif est alors un ordinaire pour la prochaine version, et aucun backporting/fusion du correctif n'est nécessaire.