Versioning et dans un héritage SCM corrections de bugs

Question

Je suis désolé pour le titre de la question terrible, mais je vais essayer de me expliquer un peu plus verbeux:

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

Un jour, j'ai remarqué un bug sérieux, présent dans les versions 1.0 et 2.0, et il doit être corrigé. Pour rendre les choses difficiles (et probablement aussi plus réalistes), je ne peux pas les corriger dans le master/trunk actuel et supposer que tout le monde l'utilise, car il y a des incompatibilités en arrière dans 2.0 avec 1.0 et les gens sont paresseux. Je ne veux pas mettre à jour. Donc, quel serait un bon système pour supporter ce genre de comportement: être capable de faire des changements dans les anciennes versions. Git semble égaliser les balises avec les versions à un certain niveau, en raison de la sortie de la commande git describe ("[latest tag]-[commits since the tag]-[current commit hash]"). Je ne peux probablement pas éviter d'utiliser des balises, alors.

Je peux sentir qu'une combinaison de balises et de branches serait une bonne idée, mais pour une raison quelconque, je ne peux pas envelopper ma tête autour des détails avec celui-ci.

Answer 1

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

A titre d'exemple, votre historique de version linéaire pourrait ressembler à ceci:

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

Si vous trouvez un bogue dans 1.0 et que vous voulez le fixer, vous ne pouvez pas simplement insérer un nouveau commit entre commits C et D. Ainsi, vous pouvez créer une branche comme ceci:

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

C1 et C2 S'engage résoudre le problème dans cette branche, où vous pouvez marquer la version 1.1. Supposons maintenant que vous ayez fait un changement (G) dans la version 2.1 que vous vouliez rétroporter vers la version 1.1 pour y apporter le même changement. 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ée à engager G sauf qu'il peut appliquer au-dessus de 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 étiquettes sont simplement un moyen pratique de créer un nom pour désigner l'état du projet à un moment donné. Git prend en charge de nombreuses autres façons de manipuler les branches, en particulier avec la puissante commande git rebase.

Answer 2

Vous avez besoin d'une branche - vous effectuerez des correctifs de maintenance et des versions sur une branche qui commence à la balise release, alors que le développement en cours se poursuit sur la branche principale (maître).

Answer 3

Vous semblez avoir déjà la plupart de la réponse lorsque vous mentionnez des branches et des tags. Un tag est là pour marquer un certain pair (comme une release) et les branches sont pour le développement parallèle. La maintenance d'une certaine version est généralement effectuée sur une branche et vous pouvez chéroter des changesets avec la plupart des VCS actuels pour importer une correction de bogue donnée de head/trunk dans une branche et vice-versa.

Vous pouvez travailler sur head/trunk/master (quelle que soit votre branche de développement "actuelle") et fusionner les corrections de bugs dans vos différentes branches de maintenance. Dès que vous avez effectué une version majeure ou mineure, vous créez une branche pour la maintenance.

Il existe plusieurs façons d'obtenir ce que vous voulez.