¿Cómo debo controlar las versiones de mi proyecto en GitHub?

Estoy tratando de pasar todo el tiempo que pueda en GitHub hoy en día (incluso yo soy la única persona en el equipo de trabajo) para sentir realmente cómo será para una aplicación corporativa del mundo real.

Una pregunta que tengo es controlar la versión . Digamos que comenzamos un proyecto. Luego, los miembros del equipo crearon algunas ramas y se desarrollaron allí. Cuando estamos listos para la producción, fusionamos todas las sucursales con mastersucursal. Al final, vamos a vivir con la versión 1.0.

Ahora esa versión 1.0está en vivo y tenemos algunos problemas archivados para esa versión de ese software. Nos gustaría comenzar a desarrollar para la versión1.1 para solucionar los problemas que habíamos introducido al apresurar el proyecto.

Ahora, la pregunta es esta:

¿Cómo deberíamos controlar el versionado aquí?

¿Deberíamos crear una nueva sucursal v1.0y mantener la versión 1.0del software allí y desarrollarla en algunas sucursales (o no), fusionarlas mastercon la versión en vivo 1.1?

¿Existe alguna convención para ese tipo de situaciones?

— tugberk
fuente

Respuestas:

Encontré (y comencé a adoptar) el siguiente modelo de sucursal :

Imagen de nvie.com

^{(imagen del artículo)}

Hay muchas buenas prácticas y reglas estrictas descritas en ese artículo, lo recomiendo encarecidamente.

Puntos de interés:

La rama maestra es donde etiqueta sus versiones. Ningún desarrollo sucede aquí. En caso de que se haya implementado un error en la producción, puede corregir el error en una rama de revisión, fusionar y etiquetar una nueva versión.
El desarrollo ocurre en las ramas de desarrollo y características. Personalmente, hago correcciones de errores en la rama de desarrollo y características en las ramas de características.
Cuando el software comienza a alcanzar una versión, me ramifico para liberar la rama. La rama de lanzamiento es donde hago los toques finales. Cambie los números de versión, cambie los metadatos, etc. Y correcciones de errores menores. Cuando termina, lo fusiono para masterizar, etiquetar y llamarlo versión.
Las dos ramas principales: maestro es la "rama sagrada"; su HEAD es siempre el último código de producción, y el desarrollo es la rama nocturna; su HEAD siempre refleja las últimas (pero posibles inestables) adiciones al código.

En su caso específico, los pasos dependerán de cuán apresurada fue esa versión. Si se excluyeron las características, volvería a la versión de desarrollo y volvería a hacer todo. Si se trata de errores en la versión implementada, me desviaría a una rama de revisión, corregiría los errores, fusionaría y etiquetaría v1.1. Si es ambas cosas, primero corregiría los errores y luego agregaría las características en segundo lugar como se describe.

— Tamás Szelei
fuente

Muy informativo y detallado. Y también una práctica perfecta. También tiene mucho sentido. Tener un maestro para la producción solo hace que sea fácil de mantener. No estoy tan familiarizado con el etiquetado de una rama (¿o commit?). ¿Me puede dar algunos detalles al respecto? ¿Cómo podemos hacer según el modelo anterior?

— tugberk

En git, el objetivo del etiquetado es una confirmación. Significa que usted dice: "aquí está este commit, y lo llamo 'v1.3' de ahora en adelante". En la práctica, eso significa que cambia a la rama maestra, se fusiona en la rama de desarrollo (ahora estable), confirma y etiqueta. Luego puede enumerar todas las etiquetas, volver a ese código en caso de que necesite ver lo que entró en producción en una versión anterior. Hay un poco más de etiquetas que eso (lo cual es útil para el desarrollo distribuido a gran escala, como el kernel de Linux). Si está interesado, le sugiero el libro progit .

— Tamás Szelei

ProGit es uno de los libros que definitivamente leeré desde cero. Por ahora solo estoy leyendo las partes que me interesan para hacer el trabajo. Hasta ahora, nos hemos desarrollado en la rama maestra y creo que debería mantener eso. Pero abriré otra rama llamada productiony la usaré como masterrama de acuerdo con el modelo anterior.

— tugberk

Mientras estoy probando este modelo, una cosa con la que estoy luchando es que hay algunas ramas de soporte como se discutió en el artículo dado, las características y las ramas de lanzamiento. puede haber múltiples ramas futuras. Por ejemplo, FeedbackForm es una rama futura y ContactForm es otra. ¿Esto está bien para este modelo, supongo? ¿Debería haber múltiples ramas de liberación también? y si es así, ¿cómo debo nombrarlos?

— tugberk

En primer lugar, no necesita seguirlo al pie de la letra, solo tiene reglas establecidas que usted mantenga. Haga lo que sea mejor para usted y el estilo de su equipo. Segundo, sí, las funciones múltiples y las ramas de lanzamiento son normales a menos que tenga un proyecto de corta duración con una función y un lanzamiento :). Nombramiento, según el artículo, es release- * y feature- *. Supongo que coloca el número de versión futura en lugar del asterisco para el lanzamiento, y la identificación del rastreador de problemas en el caso de las ramas de características.

— Tamás Szelei

Lo que he presenciado la mayor parte del tiempo es:

Master es para tu producto. Eventualmente, toda su futura versión x.0 estará en master.
Puede crear una etiqueta / rama para cada versión en producción para poder seguir siendo compatible con cualquier cliente que lo requiera.
Fusionar arreglos de uno u otro es tratar según cada caso.

— xsace
fuente

¡Gracias! Entonces, ¿cree que es razonable mantener una rama llamada v1.0, v1.2 es razonable?

— tugberk

@tugberk, mientras exista el software correspondiente en esa versión, tiene sentido mantener las ramas alrededor para que pueda bifurcarlas rápidamente si necesita una rama de revisión específica. Cuando el software ya no existe en esa versión (ya no es compatible, por lo que no puede realizarse más trabajo), puede tener sentido hacer una fusión final de la rama y luego eliminarla. Incluso puede crear una confirmación vacía final (lo hago a menudo al comienzo de la rama), solo para decir "Cerrar rama XXXX", de lo contrario no mantendrá el historial de la rama (reflog puede ayudar un poco, pero esto es por repositorio)

— Patrick Mevzek