Versiones y corrección de errores heredados en un SCM

Question

Lamento mucho el horrible título de la pregunta, pero intentaré explicarme un poco más detalladamente:

Estoy usando Git (pero supongo que el software en particular realmente no importa en este caso) para mi proyecto de software. Como muchos proyectos, planeo tener varios lanzamientos. Cuando hay un lanzamiento, probablemente asignaría una etiqueta de confirmación, por ejemplo " 1.0 " ;. El tiempo pasa y el código se piratea, y finalmente hay un lanzamiento, con otra etiqueta, esta vez "2.0".

Un día, noto un error grave, que está presente en las versiones 1.0 y 2.0, y necesita ser reparado. Para hacer las cosas difíciles (y probablemente también más realistas), no puedo simplemente arreglarlo en el master / trunk actual y asumir que todos lo usarían, porque hay algunas incompatibilidades hacia atrás en 2.0 con 1.0 y las personas son flojas No quiero actualizar.

Entonces, ¿cuál sería un buen esquema para soportar este tipo de comportamiento ?: poder realizar cambios en versiones anteriores. Git parece equiparar etiquetas con lanzamientos en algún nivel, debido a la salida del comando git describe (" [última etiqueta] - [confirma desde la etiqueta] - [hash de confirmación actual] "). Probablemente no pueda evitar usar etiquetas por completo, entonces.

Puedo sentir que una combinación de etiquetas y ramas sería una buena idea, pero por alguna razón no puedo entender las particularidades con esta.

Answer 1

Definitivamente, usted quiere considerar el uso de una rama para esto. Git apoya ramas para este tipo de desarrollo muy bien.

A modo de ejemplo, su historial de versiones lineales podría verse así:

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

Si encuentra un error en 1.0 y desea solucionarlo, no puede simplemente insertar una nueva confirmación entre las confirmaciones C y D. Por lo tanto, puede crear una rama como esta:

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

Los commits C1 y C2 solucionan el problema en esa rama, donde puede etiquetar la versión 1.1. Ahora suponga que realizó un cambio (G) en la versión 2.1 que deseaba incluir en la versión 1.1 para realizar el mismo cambio allí. Puede usar git cherry-pick para hacer lo siguiente:

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

El commit G1 está relacionado con el commit G, excepto que puede aplicarse sobre la versión 1.1 en lugar de la versión 2.0.

En estos ejemplos, las ramas (flujos adicionales de desarrollo) son el concepto clave, mientras que las etiquetas son solo una forma conveniente de hacer un nombre para referirse al estado en el que se encontraba el proyecto en un momento determinado. Git admite muchas otras formas de manipular ramas, especialmente con el poderoso comando git rebase .

Answer 2

Necesita una rama: realizará correcciones de mantenimiento y versiones en una rama que comienza en la etiqueta de la versión, mientras que el desarrollo continuo continúa en la rama principal (maestra).

Answer 3

Parece que ya tiene la mayor parte de la respuesta cuando menciona ramas y etiquetas. Hay una etiqueta para marcar un determinado par (como una versión) y las ramas son para el desarrollo paralelo. El mantenimiento de una determinada versión generalmente se realiza en una rama y puede seleccionar los conjuntos de cambios con la mayoría de los VCS actuales para importar una corrección de error determinada desde la cabeza / tronco a una rama y viceversa.

Puede trabajar desde head / trunk / master (cualquiera que sea el nombre de la rama de desarrollo actual) y combinar correcciones de errores en sus diversas ramas de mantenimiento. Tan pronto como haya realizado una versión mayor o menor, crea una rama para mantenimiento.

Hay muchas formas de lograr lo que quieres.