Gestion des versions et corrections de bogues héritées dans un GDS

Question

Je suis vraiment désolé pour le titre épouvantable de la question, mais je vais essayer de m'expliquer un peu plus verbalement:

J'utilise Git (mais je suppose que le logiciel en question n'a pas vraiment d'importance dans ce cas) pour mon projet de logiciel. Comme beaucoup de projets, je prévois plusieurs versions. Quand il y a une release, j'attribuerais probablement un commit à un commit, par exemple "1.0". Le temps passe et le code est piraté, et finalement il y a une version, avec une autre balise - cette fois "2.0".

Un jour, j'ai remarqué un bogue grave, présent dans les versions 1.0 et 2.0, et qui doit être corrigé. Pour rendre les choses difficiles (et probablement plus réalistes aussi), je ne peux pas simplement le réparer dans le tronc principal actuel et supposer que tout le monde l'utilisera, car il existe des incompatibilités en amont dans la version 2.0 avec la version 1.0 et que les utilisateurs sont paresseux et don ne voulez pas mettre à niveau.

Alors, quel serait le bon stratagème pour supporter ce type de comportement: être capable de modifier des versions plus anciennes. Git semble assimiler les balises à des versions d'un certain niveau, en raison de la sortie de la commande git describe (" [dernière balise] - [commet depuis la balise] - [hachage de validation actuelle] "). Je ne peux probablement pas éviter d'utiliser des tags, alors.

Je peux penser qu'une combinaison de balises et de branches serait une bonne idée, mais pour une raison quelconque, je ne peux pas comprendre les détails avec celui-ci.

Answer 1

Vous voulez vraiment utiliser une branche pour cela. Git supporte très bien les branches pour ce type de développement.

À titre d'exemple, l'historique de vos versions linéaires pourrait ressembler à ceci:

---A---B---C[1.0]---D---E---F[2.0]---G---H

Si vous trouvez un bogue dans la version 1.0 et souhaitez le résoudre, vous ne pouvez pas simplement insérer un nouveau commit entre les commits C et D. Vous pouvez donc créer une branche comme celle-ci:

---A---B---C[1.0]---D---E---F[2.0]---G---H[2.1]
            \
             C1---C2[1.1]

Les validations C1 et C2 résolvent le problème dans cette branche, où vous pouvez baliser la version 1.1. Supposons maintenant que vous ayez apporté une modification (G) dans la version 2.1 que vous souhaitiez rétroporter vers la version 1.1 pour y apporter les mêmes modifications. Vous pouvez utiliser git cherry-pick pour effectuer les opérations suivantes:

---A---B---C[1.0]---D---E---F[2.0]---G---H[2.1]
            \
             C1---C2[1.1]---G1[1.2]

Commit G1 est lié à commit G sauf qu'il peut s'appliquer par-dessus la version 1.1 au lieu de la version 2.0.

Dans ces exemples, les branches (flux de développement supplémentaires) constituent le concept clé, tandis que les balises ne sont qu’un moyen pratique de nommer l’utilisateur dans l’état du projet à un moment donné. Git supporte de nombreuses autres manières de manipuler des branches, notamment avec la puissante commande git rebase .

Answer 2

Vous avez besoin d'une branche. Vous effectuerez des correctifs et des versions de maintenance sur une branche qui commence par l'étiquette de version, tandis que le développement en cours se poursuit sur la branche principale (principale).

Answer 3

Vous semblez déjà avoir la plupart des réponses lorsque vous mentionnez des branches et des tags. Une balise est là pour marquer un certain seuil (comme une version) et les branches sont destinées au développement parallèle. La maintenance d’une certaine version s’effectue généralement sur une branche et vous pouvez effectuer des Cherrypick avec la plupart des VCS actuels pour importer un correctif de bogue donné de la tête / du coffre dans une branche et inversement.

Vous pouvez travailler à distance / dans le coffre / dans le maître (quel que soit le nom de votre branche de développement actuelle) et fusionner les corrections de bugs dans vos différentes branches de maintenance. Dès qu'une version majeure ou mineure est terminée, vous créez une branche pour la maintenance.

Il existe de nombreuses façons de réaliser ce que vous voulez.