¿Cómo se colocan diferentes versiones de su biblioteca bajo control de versiones? ¿Usas etiquetas? O ramas? ¿U otro método?

24

Recientemente comencé a poner mi código bajo control de versiones (en el laboratorio en el que estoy trabajando, bajo SVN, y mis propios códigos en github (obviamente con git)). Antes de usar el control de versiones, solía hacer algo como esto. Tenía una carpeta con el nombre de la biblioteca, dentro de muchas carpetas con el número de versión. Cada vez que quería comenzar a trabajar en una versión más nueva, hacía una copia de la última versión, cambiaba el nombre a la nueva versión y comenzaba a implementarla.

Sin embargo, esto parece redundante cuando la carpeta se pone bajo control de versión. Además de la redundancia, si alguien quiere obtener la última versión, descargaría todas las versiones si solo fuera imports / clones.

Ahora veo muchas formas de hacerlo con el control de versiones, pero como soy nuevo en esto, no sé cuál sería más fácil de mantener.

Método 1: uso de etiquetas

Si entendiera correctamente las etiquetas, tendría su rama principal, confirmará cualquier cambio que tenga y las etiquetará con una versión. Luego, cuando desea obtener una copia de trabajo de la misma, obtiene la que tiene una determinada etiqueta. (corrígeme si me equivoco)

Método 2: versiones de ramificación

En este método, la rama principal sería la rama de desarrollo. De vez en cuando se hace una versión estable (digamos v1.2.0), se crea una rama para esa versión y nunca se compromete. De esa manera, si desea descargar una determinada versión, obtendrá el código de esa rama. Aunque dije que nunca se compromete a ello, es posible hacer correcciones de errores y comprometerse con la rama de una versión anterior para mantener la versión anterior en ejecución. Por ejemplo, si la versión actual es v2.0, pero hay personas que quieren usar v1.2, puede obtener otra rama v1.2, a saber, v1.2.1y confirmar las correcciones de errores, o simplemente mantener la versión igual v1.2y simplemente confirmar las correcciones de errores.

Entonces las ramas se verían así:

                  v1.2.1  v1.2.2
                 /       /
 v1.0.0   v1.2.0---------     v2.0.0
/        /                   /
-------------------------------------- dev

De esta forma, tiene sucursales para cada actualización de versión menor. (Tenga en cuenta que en el gráfico anterior, v1.2.1 y v1.2.2 o creado después de que se lanzó v2.0.0, por lo que no formaron parte del desarrollo entre v1.2.0 y v2.0.0. Piense en ello como soporte para versiones anteriores)

Método 3: desarrollo de ramificaciones

Este método es lo opuesto al anterior. La rama principal sería la última versión estable. Siempre que esté trabajando en una nueva versión, cree una rama (para el desarrollo), trabaje en su código y cuando sea estable, combínelo con la rama principal.

En este caso, las ramas se verían así:

 ________  ____  ________________  _____ dev
/        \/    \/                \/
---------------------------------- latest_version

Probablemente este debe hacerse junto con las etiquetas ¿verdad?

¡La pregunta!

De todos modos, mi pregunta es que, según su experiencia, ¿cuál de estos métodos resulta más práctico? ¿Existe un mejor método conocido por ahí (que posiblemente no descubrí yo mismo)? ¿Cómo se hacen comúnmente estas cosas?

version-control git svn branching release-management Shahbaz
fuente

Respuestas:

17

Las etiquetas y las ramas no son mutuas, puede (y la OMI generalmente debería) usar ambas. Las etiquetas están ahí para marcar hitos en el desarrollo. Por ejemplo, se abra una rama de la versión 1.2 de su producto, y se marca v1.2 Beta, RC1, RC2, Final(y luego, si es necesario, SP1etc.) con las etiquetas en la misma rama.

Personalmente prefiero el Método 2 como el enfoque predeterminado (aunque trato de evitar múltiples niveles de ramas, para mantener la vida lo más simple posible). El método 1 simplemente no va a funcionar en la vida real: las etiquetas no son suficientes, necesitas ramas. Y el método 3 es inflexible porque solo tiene una versión estable en todo momento, por lo que (a menos que lo combine con el Método 2), no puede mantener varias versiones (más recientes y más antiguas) en paralelo. Esto es necesario para casi todos los proyectos en la vida real: mientras trabaja en la versión 2, aún debería poder publicar parches / actualizaciones para v1.9, y a menudo incluso versiones anteriores. Mucho depende del tipo de aplicación, por supuesto. Desarrollamos una aplicación web, por lo que solo hay una versión de producción en un momento dado, pero a menudo hacemos malabares con 3 versiones diferentes (una en producción, uno está en UAT preparándose para la implementación, uno es la última versión en el tronco). Puede ser mucho más complejo para una aplicación de escritorio / cliente con múltiples versiones antiguas que se usan, y se mantienen, en paralelo.

Péter Török
fuente
Bueno, como dije, el Método 3 podría venir en combinación con etiquetas, por lo que tiene etiquetas para confirmaciones estables. No estoy seguro, si tengo las etiquetas correctas, pero usted etiqueta una confirmación y luego puede obtener el repositorio con la confirmación que tiene esa etiqueta. Si es así, tiene muchas versiones estables, pero están en la misma rama (bajo diferentes etiquetas)
Shahbaz
@Shahbaz, sí, pero el punto es que las versiones etiquetadas son de solo lectura, no puedes hacer cambios en ellas. Esto significa que no puede corregir errores en versiones anteriores mientras desarrolla nuevas funciones en el tronco.
Péter Török
No olvides que solo puedes usar etiquetas y si necesitas volver y arreglar algo para una versión anterior, puedes convertir esa etiqueta en una rama cuando la necesites.
Chloe
6

Tenía una carpeta con el nombre de la biblioteca, dentro de muchas carpetas con el número de versión.

Esto es efectivamente, como notará, un enfoque incorrecto, ya que ya tiene el control de versión para ... controlar las versiones.

Ahora, las diferentes técnicas que enumeras parecen igualmente correctas. Puede leer un artículo muy detallado, Source Control Done Right , que incluye información sobre etiquetas y ramas.

Arseni Mourzenko
fuente
Sí, el primer método era lo que solía hacer antes de tener mi código bajo control de versiones. Leeré tu enlace y te lo haré saber
Shahbaz
El enlace fue genial. Tengo la sensación de que el Método 2 es mejor (al menos para mí, que básicamente soy el único desarrollador de las bibliotecas)
Shahbaz
3

Los tres métodos no son mutuamente excluyentes, y debe combinar los tres para aprovechar al máximo su control de versiones.

Por mi parte, utilizaría una combinación de los métodos 1 y 3 de forma predeterminada, es decir, desarrollar en una característica o rama de desarrollo hasta que una característica esté lista para la producción y luego volver a fusionarse en el tronco. De esta forma, el enlace troncal siempre representa el estado actual del desarrollo estable que se utilizará y puede vincularse de manera segura mediante svn: proyectos externos. Cuando lance una versión, etiquétela.

Sólo había rama de la demanda, es decir, cuando las versiones anteriores de la biblioteca tienen un error que tiene que ser fijo. Puede crear fácilmente esa rama desde la etiqueta de la versión rota. Al no ramificarse innecesariamente, mantiene baja la cantidad de ramas y tiene una visión general rápida de los bordes sangrantes que deben mantenerse (tronco y todas las ramas).

thiton
fuente
2

Yo usaría el Método 2 . Utilicé esto y descubrí que es una forma efectiva de administrar y mantener múltiples versiones al tiempo que permite que el desarrollo actual avance. También puede usar etiquetas junto con este método si las necesita.

Vea mi respuesta aquí para obtener más información sobre el uso de la ramificación para mantener varias versiones de lanzamiento.

Bernardo
fuente