De qué twig hacer un package de producción en flujo de git

Estamos usando git flow atm en nuestro equipo, y seguimos volviendo a una pregunta.

¿De qué twig hacer un package para implementar desde producción?

Si crea una twig de lanzamiento y la testing en el entorno de testing, entonces tiene sentido tomar la misma construcción y simplemente implementarla en producción. Pero si entendí que git brillará correctamente, lo que debes hacer es fusionar la twig de publicación en maestra primero (crea una label con número de versión) y desplegar una nueva compilation desde la twig maestra hasta la producción. Eso también tiene sentido, porque nuestro sistema de compilation agrega el último compromiso SHA de la twig al número de versión, por lo que podemos encontrar fácilmente qué versión está actualmente activa y la label corresponde al código implementado actualmente.

Ahora sé que la base de código de la twig de publicación y la twig principal debe ser exactamente 1: 1, pero el hecho es que estás implementando un package no probado para la producción, lo que pone a algunas personas en el equipo un poco nerviosas: P

Así que pensé que podría preguntar aquí, ¿cuál crees que es el mejor enfoque para esto?

Figura 1

El código en tus círculos rojos debería ser idéntico. El maestro solo se cambia por fusiones, y nada allí no ha llegado a la twig de publicación en este punto. Si fueran diferentes (después de esa fusión), eso indicaría un problema de process.

Dicho esto, la idea de las twigs, en mi entender, es que siempre se libera del maestro. ¿De dónde vendría la versión 0.2, de lo contrario?

En ese diagtwig, implementaría la producción desde el maestro después de fusionar la twig de publicación en el maestro.

Si hacer eso pone nerviosos a algunos en el equipo, sugeriría que puede deberse a un malentendido acerca de cómo maneja Git las fusiones. Cuando fusiona la twig de publicación en master con los commands:

git co master git merge release-branch 

El código en las dos twigs será idéntico. Si quieres comprobarlo por ti mismo, puedes ejecutar git diff release-branch y ver las diferencias.