Flujo de trabajo de Git para manejar múltiples versiones y correcciones de emergencia.

Tenemos un repositorio de Git con una rama principal.
Todos los desarrolladores crean una rama de características desde la principal y luego lo envían de vuelta.
Cuando estamos listos para el lanzamiento, creamos una etiqueta en la rama principal y, después, creamos un lanzamiento desde ahí.
El lanzamiento (un archivo EAR) se implementa en aceptación. Una vez validado, el mismo archivo EAR se implementa en producción.
Si hay algún problema en el entorno de aceptación, creamos otra rama desde la principal y la fusionamos de nuevo con la principal. Luego, seguimos el mismo proceso de lanzamiento.

Esto suele funcionar bien la mayor parte del tiempo, sin embargo, como la rama principal no es siempre la misma que la versión de producción (los desarrolladores fusionan las ramas de características directamente con la principal), llevar a cabo parches de corrección antes de la siguiente versión principal es un desafío. La versión semver de una versión principal es siempre X.Y.Z.0, X.Y.Z+1.0, X.Y.Z+2.O, etc.

En este momento, creamos una rama de parche de la etiqueta (la que está en producción, no la etiqueta más reciente) y la corregimos y lanzamos como una rama separada. Luego, vuelve a aceptación y se valida antes de implementarse en producción. La versión semver para los parches de corrección es X.Y.Z.1, X.Y.Z.2…., etc.

Una vez validado un parche de corrección, implementamos el archivo EAR en producción. Luego, fusionamos el parche de corrección con la rama principal. La fusión tiene que hacerse manualmente ya que la versión del archivo POM del parche de corrección y la principal son diferentes.

¿Hay una mejor manera de manejar esto?

He explorado Gitflow y otros flujos similares, pero realmente no abordan este problema, ya que todos consideran que la rama principal es la única fuente de verdad para la producción, lo cual no es el caso para nosotros.

Podemos crear más ramas si eso nos ayuda. Usamos Gitlab.