Este es el problema exacto que tengo con gitflow y GitHub flow, y parece que con las aplicaciones web esto ocurre con frecuencia, o más bien como la norma. Parece que resolvería este problema de forma retroactiva (mencionada anteriormente) o proactivamente (ejemplo a continuación).
He creado 'ramas de paquete' además de las ramas de gitflow estándar. El paquete consta de todas las características que están listas para uat / qa. Se crea una lista de características de uat / qa. Estos se combinan en el paquete temporal, y ese paquete se implementa en uat / qa. Cualquier corrección de errores ocurre en la rama de la característica original, y se vuelve a agregar al paquete y se despliega. Esto separa la próxima versión y permite probar esas características en conjunto antes de que encuentren su camino hacia la rama de desarrollo. Las sucursales que están aprobadas obtienen una solicitud de extracción para desarrollarse, siguiendo el proceso de gitflow. Las funciones preparadas para la prueba se pueden agregar o quitar de la rama del paquete temporal
y redistribuido.
- Esto mantiene al maestro siempre reflejando el estado listo para producción (se puede automatizar con gancho)
- Develop siempre refleja el último lanzamiento entregado (y probado) candidato para el próximo lanzamiento
Las desventajas incluyen administrar la lista de paquetes y agregar otro tipo de rama; sin embargo, además de la solución retro, que creo que es demasiado tarde, esta parece ser la solución más viable.
Con un complemento GUI, podría ser óptimo marcar las ramas de características por despliegue de paquete, con la automatización en mente.