¿A dónde van las correcciones de errores en el modelo git-flow?

En el, comúnmente conocido, las revisiones del modelo Git-flow van en su hotfix-*rama específica y las pequeñas correcciones de integración justo antes del lanzamiento van en la release-*rama. Las correcciones de errores generales de la versión anterior no parecen tener un lugar.

¿Dónde deberían aparecer? ¿Deberían estar en su propia bug-*rama ramificándose develop(al igual que las featureramas)?

git gitflow

— Zapato
fuente

¿Por qué un error no crítico en el código lanzado sería diferente de una característica pequeña para producir un comportamiento diferente al que hace actualmente la aplicación?

— Bart van Ingen Schenau

@BartvanIngenSchenau ¿Está recomendando que sean feature-*sucursales? ¿Se puede ver una solución en un comportamiento erróneo como una característica?

— Zapato

@ Zapato Creo que lo que Bart quiere decir es que debes tratarlos como características, no necesariamente usando el mismo prefijo de rama .

— Darkhogg

@Shoe: en git-flow, cualquiera de las ramas, excepto master, develop, release-*o hotfix-*es una rama de la característica, por lo que puede utilizar cualquier prefijo te gusta y utilizar un prefijo diferente para los insectos. Además, ¿cuál es la diferencia entre el comportamiento erróneo que funciona como especificado y el comportamiento erróneo que se desvía de la especificación? En ambos casos es un comportamiento erróneo, pero solo el último es un error.

— Bart van Ingen Schenau el

La respuesta breve: Sí, las ramas para la corrección de errores que se incluirán en una próxima versión planificada deben estar en las ramas de funciones. La forma en que nombra las ramas de características o estas ramas para la corrección de errores depende de usted y de los estándares de su equipo, pero deben tratarse de manera idéntica si está siguiendo Gitflow.

El comentario de Bart van Ingen Schenau plantea un buen punto.

Gitflow tiene cinco tipos de la rama: master, develop, ramas de revisión (con el prefijo hotfix-), ramas de liberación (con el prefijo release-, y las ramas de características El. masterY developramas son ramas de larga duración y no se comprometen directamente en ellas Los. release-Se hacen ramas para dibujar una línea para una versión en particular y luego admite correcciones de errores entre la identificación de la próxima versión y la versión. Las hotfix-ramas son específicamente para versiones críticas fuera de ciclo en producción. Las feature-ramas son para el desarrollo de características individuales para alguna versión futura.

Procedentes de entornos en los que se utilizan los RP y aparte de un desarrollador individual de comprometerse a una rama de la característica, nada debe comprometerse directamente en master, developo una rama de lanzamiento. Esto garantiza que cada cambio se revise en código, junto con garantizar una cobertura de prueba adecuada y pasar las pruebas en un entorno de CI antes de que entren los cambios. Me opondría a cualquier confirmación directamente en una de estas ramas, aunque parece que Gitflow por sí solo no No tiene ningún problema para realizar correcciones de errores previos al lanzamiento o cambios directamente en la rama de lanzamiento y luego llevarlos al desarrollo y luego a las ramas de características.

En su caso particular, una release-sucursal no es un lugar apropiado. El software ya ha sido lanzado y está en master. Una vez que una versión se fusiona con master y se etiqueta allí, la rama de publicación para esa versión en particular ha sobrevivido a su propósito y ya no necesariamente necesita existir. Si eres activo en la limpieza de tus ramas (que creo que todos deberían serlo), entonces esto ni siquiera es una opción.

Si su solución no es crítica, entonces tampoco parece encajar una rama de revisión. El propósito de una rama de revisión es permitir que alguien obtenga cambios críticos en la producción muy rápidamente sin interferir con el desarrollo continuo. El uso de estos debería ser la excepción y no la norma para un equipo de desarrollo. En general, las revisiones críticas deberían ser un caso excepcional.

Lo único que queda es una rama de características. Tenga en cuenta que la sección de la página vinculada a la pregunta sobre las ramas de características incluso dice que las ramas de características se denominan "ramas de temas". Si su cambio está dirigido a una próxima versión y no cumple con los criterios para una revisión, debería estar en una de estas ramas.

— Thomas Owens
fuente

Estamos de acuerdo en que no debe haber compromisos directos para dominar, desarrollar o liberar sucursales. Pero, ¿cuál debería ser el flujo de PR cuando encuentra un error en la rama de lanzamiento y necesita ser reparado en ambas ramas de lanzamiento y desarrollo? Esto tiene sus propios desafíos si toda su rama de lanzamiento aún no está lista para fusionarse en el desarrollo, pero la corrección de errores debe hacerse en ambos lugares. Si lo desea, puedo publicar una nueva pregunta para esto.

— Sap

@Sap Una nueva pregunta sería buena, pero si la publica, explique por qué la solución es tan crítica que debe fusionarse en ambas, lo que parece implicar que hubo un problema crítico que no se encontró antes de que se introdujera develop, no encontrado entre el momento en que se introdujo y la creación de la rama de lanzamiento, y / o que su rama de lanzamiento existe durante mucho tiempo. Simplemente, sin embargo, creo que la única opción es una selección de cereza (sugeriría una solicitud de reparación y extracción en la rama de lanzamiento, fusionarla en la rama de liberación y desarrollar una selección de cereza mediante una solicitud de extracción).

— Thomas Owens

Si se trata de una única confirmación, simplemente realice una confirmación bien identificada y póngala en la parte superior de la rama de desarrollo; de lo contrario, cree una rama de características.

También hay un comentario del autor de git-flow que dice exactamente lo que está preguntando: Faltan ramas de corrección de errores # 24

— Debutante
fuente

Gracias, ese enlace que compartiste me lo aclaró.

— arcseldon