¿Cuál es la forma recomendada de separar el desarrollo actual del desarrollo de mantenimiento en el software de control de versiones?

Tengo alguna aplicación de software administrada usando Git. Acabo de lanzar una nueva versión 2.x que planeo mantener a largo plazo (la mayoría de las correcciones de errores). Mientras tanto, me gustaría comenzar a trabajar en la versión 3.x. ¿Cuál es la forma recomendada de gestionar esto? ¿Debo crear una rama para la versión 2.xy tener el desarrollo 3.x en el maestro? o al revés?

version-control git

— Laurent
fuente

Tener una rama diferente para el desarrollo y estable.

— Oded

Entonces, ¿qué suele pasar en la rama maestra? (hasta ahora siempre hago todo allí)

— laurent

Debes decidir qué quieres masterdecir. Es solo una etiqueta.

— Oded

Respuestas:

Aquí se describió una forma muy interesante de hacer las cosas: un modelo de ramificación Git exitoso

Lo encontré muy intrigante, pero aún no lo he usado.

Muy bien, como solicitó un resumen (muy) breve de lo que dice el artículo:

La rama maestra solo representa los hitos terminados (es decir, la versión 1.0, 1.1, 1.2, etc.)
El desarrollo se realiza en su propia rama (convenientemente llamado "desarrollo", ¿quién lo hubiera pensado?). La rama de desarrollo se fusiona nuevamente con la rama maestra, cada vez que se realiza una versión completa de la característica.
Ramificación del desarrollo son ramas de características. Estas representan características únicas para la próxima versión (o cualquier versión futura). Se fusionan con la rama de desarrollo.
Otra rama que viene del desarrollo es la rama de "lanzamiento". Esta es una rama que representa una versión de lanzamiento casi completa donde solo se deben limpiar detalles menores. Se fusiona con la rama de desarrollo y, en última instancia, con la rama maestra.
La rama "Hotfix" se ramifica desde la rama maestra si encuentra un error grave en una de sus versiones (es decir, "Si el uso ingresa el código konami, nuestro programa formateará el disco duro principal ..."). Se ramifica desde la versión con errores y, cuando finaliza la corrección, se fusiona de nuevo con la rama maestra Y la rama de desarrollo.

Eso es todo, pero confía en mí, que el artículo lo describe con más detalle, y con el útil gráfico de visualización es mucho más fácil de entender.

— Sorcy
fuente

Debe incluir alguna explicación sobre su sugerencia en la respuesta, preferiblemente las personas no tendrán que seguir el enlace para tener una idea general del modelo. Los enlaces tienen la mala costumbre de ir mal, y las respuestas deben ser independientes ...

— yannis

+1 Más o menos lo que usamos en el trabajo, y realmente funciona.

— Ed James

Creo que esto se conoce comúnmente como el modelo de "tronco estable" o "rama característica".

— sleske

"La rama maestra solo representa hitos terminados (es decir, Versión 1.0, 1.1, 1.2, etc.)" No quisiera una rama maestra con las versiones 1.0, 1.1, 1.2, 2.0, 1.3, 2.1, 1.4, 2.2, 3.0, 1.5 en ese orden, eso sería realmente confuso. Supongo que hay una suposición implícita de que hay como máximo una secuencia en la que se realizan lanzamientos, ese no es el caso en mi práctica. Hay primeros usuarios y personas que quieren algo más estable.

— Programador el

Bueno, a la larga, una sucursal no es más que una etiqueta para que le resulte más fácil saber qué sucede allí. Por lo tanto, si no le gusta de esta manera, no hay nada que le impida usar la rama Maestra solo para versiones estables de alcalde y tener una Rama "de prueba" (o como quiera llamarla) para versiones incrementales más pequeñas.

— Sorcy

Mi principio es que cuanto más corta sea la rama, más profunda debería ser en la estructura de la rama y más específico será su nombre. Cuanto más larga sea la rama, más superficial será en la estructura de la rama y más genérico será su nombre.

Por lo tanto, conserva su maestro para la versión a largo plazo (3.X) y sigue nombrando esta rama con un nombre genérico (maestro, troncal, desarrollo, ...) y no uno específico (nombre de código de lanzamiento o incluso números de lanzamiento peores) que dependen demasiado en la práctica de la decisión de comercialización tardía)

No importa tanto en un sistema como git que tiene un espacio de nombre plano para ramas y donde las ramas son equivalentes. Importa más con un sistema como clearcase que tiene un espacio de nombres jerárquico para ramas (el nombre completo de la rama V4 termina siendo main / v1 / v2 / v3 / v4 ...)

— Un programador
fuente

+1, excepto que no sé qué significa realmente profundo y superficial en este contexto, ¿tal vez podría expandirse un poco en esos términos?

— Michael Durrant

Piensa en las ramas que hacen un árbol. Pueden salir del tronco u otra rama. Poco profundo significa que el número de pasos de ramificación entre la rama y el tronco es pequeño, profundo significa que el número de pasos de ramificación es importante. Lo pequeño e importante es en su mayoría relativo, pero he visto esquemas para los cuales cada nueva versión fue un paso más allá que la anterior desde el tronco. Si está utilizando un espacio de nombres plano, eso no es tan malo. Si el espacio de nombres es jerárquico (clearcase, CVS, RCS, Perforce también se puede usar de esa manera), obtendrá nombres cada vez más largos.

— Programador