Buscamos en el mundo on line y así de esta manera tenerte la solución a tu dilema, si continúas con alguna difcultad puedes dejar tu pregunta y te responderemos con gusto.
Solución:
Flujo de GitLab propone usar master y feature ramas también. Una vez que la función está lista, la fusionamos de nuevo a master sucursal. Esta parte se ve igual que en Flujo de GitHub.
Entonces, entiendo que nos dan 2 opciones sobre cómo hacerlo, dependiendo de si se trata de una aplicación SAAS o una aplicación móvil (que se puede lanzar al mundo).
Si se trata de una aplicación SAAS, usamos ramas de entorno, por ejemplo. pre-production y production. Estas ramas se crean a partir de la master cuando estemos listos para implementar nuestra aplicación. Tener diferentes sucursales por entorno nos permite configurar la herramienta CI/CD para que se implemente automáticamente en las confirmaciones realizadas en estas sucursales. Si hay un problema crítico, lo solucionamos en feature o master bifurcar y luego fusionarlo con environment sucursales.
En cuanto a las aplicaciones que se pueden lanzar al mundo (por ejemplo, aplicaciones móviles o de escritorio), entiendo que proponen usar un modelo diferente usando release sucursales en lugar de sucursales de entorno. Todavía hacemos todo el trabajo en feature ramas y fusionarlos de nuevo a master rama al finalizar. Luego, cuando nos aseguremos de que master La rama es lo suficientemente estable, es decir, ya hemos realizado todas las pruebas y correcciones de errores que creamos. release rama y liberar nuestro software. Si hay un problema crítico, primero lo solucionamos en master ramifica y elige una solución para release sucursal.
Ha pasado un año desde que se planteó esta publicación, pero considerando a los futuros lectores y el hecho de que las cosas han cambiado un poco, creo que vale la pena actualizarlo.
Flujo de GitHub como lo describió originalmente Scott Chacon en 2011, asumió que cada cambio una vez revisado en un feature branch y fusionado en master debe implementarse en producción de inmediato. Si bien esto funcionó en ese momento y se ajustaba a la única regla de flujo de GitHub, que es cualquier cosa en la rama maestra es implementablese descubrió rápidamente que para mantener master un true registro de conocidos código de producción de trabajo el despliegue real a la producción debe ocurrir desde el feature branchantes de fusionándolo en master. Desplegando desde el feature branch tiene mucho sentido ya que en el caso de cualquier problema, la producción puede revertirse instantáneamente implementando master lo. Eche un vistazo a una breve introducción visual a GitHub Flow.
Flujo de GitLab es una especie de extensión de GitHub Flow acompañada de un conjunto de pautas y mejores prácticas que tienen como objetivo estandarizar aún más el proceso. Además de promocionar listas para implementar master rama y ramas de características (igual que GitHub Flow) presenta otros tres tipos de ramas:
Productionsucursal- Ramas de medio ambiente:
uat,pre-production,production - Ramas de lanzamiento:
1-5-stable,1-6-stable
Creo que los nombres y ejemplos anteriores son autodescriptivos, por lo que no daré más detalles.
Si haces scroll puedes encontrar las reseñas de otros desarrolladores, tú incluso eres capaz mostrar el tuyo si dominas el tema.