software - ¿Cuál es la diferencia entre GitHub Flow y GitLab Flow?

software git lab

Question

Recientemente he encontrado los tres conceptos de un flujo de trabajo en GIT: GitFlow, GitHub Flow y GitLab Flow. He leído el buen artículo al respecto ( https://docs.gitlab.com/ee/workflow/gitlab_flow.html ) pero no entiendo muy bien GitLab Flow. Tal vez porque no soy un hablante nativo :)

Brevemente.

GitFlow ( https://docs.gitlab.com/ee/workflow/gitdashflow.png ).

Tenemos una rama maestra como una rama de producción. También tenemos una rama de desarrollo donde cada desarrollador combina sus características. A veces creamos una rama de lanzamiento para implementar nuestras funciones en producción. Si tenemos un error en la versión de lanzamiento, corríjalo y arrastre los cambios a la rama de desarrollo. Si tenemos un error crítico en la producción, cree una nueva rama de revisión, corrija el error y fusione la rama con la producción (maestra) y desarrolle ramas.

Este enfoque es muy bueno si rara vez mostramos los resultados de nuestro trabajo. (Tal vez un tiempo cada 2 semanas).

GitHub Flow ( https://docs.gitlab.com/ee/workflow/github_flow.png ).

Tenemos una rama maestra como rama de producción. Y nosotros (como desarrolladores) solo podemos crear sucursales para agregar nuevas funciones o corregir errores y combinarlas con la rama de producción (maestra). Suena muy simple. Este enfoque se ajusta a la programación extrema donde la rama de producción se implementa varias veces en un día.

GitLab Flow ( https://docs.gitlab.com/ee/workflow/production_branch.png , https://docs.gitlab.com/ee/workflow/environment_branches.png , https://docs.gitlab.com/ee/workflow/release_branches.png ).

He visto nuevos términos como una preproducción, una producción, una sucursal de lanzamiento (estable) y un entorno de preparación, un entorno de preproducción, un entorno de producción. ¿Qué relaciones tienen entre ellos?

Lo entiendo de esa manera: si necesitamos agregar una nueva función, implementamos una rama de preproducción desde la rama maestra. Cuando hayamos terminado la función, desplegamos una rama de producción de la rama de preproducción. Una rama de preproducción es la etapa intermedia. Y luego la rama maestra extrae todos los cambios de la rama de producción.

El enfoque es bueno si queremos ver cada característica por separado. Simplemente verificamos en la sucursal lo que necesitamos y miramos.

Pero si necesitamos mostrar nuestro trabajo, creamos una rama de lanzamiento con una etiqueta lo más tarde posible. Si luego arreglamos errores en la rama maestra, debemos seleccionarlos en la última versión. Al final tenemos la versión de lanzamiento con etiquetas que pueden ayudarnos a movernos entre versiones.

¿Mi visión es correcta? ¿Qué diferencia hay entre el pull y el cherry pick?

Answer 1

Ha pasado un año desde que se publicó esta publicación, pero considerando los futuros lectores y el hecho de que las cosas han cambiado un poco, creo que vale la pena refrescarse.

GitHub Flow, como lo describió originalmente Scott Chacon en 2011, asumió que cada cambio una vez revisado en una feature branch y fusionado en master debe implementar en producción inmediatamente. Si bien esto funcionó en ese momento y se ajustó a la única regla de flujo de GitHub, que es que todo lo que se puede implementar en la rama maestra , se descubrió rápidamente que para mantener un registro verdadero del código de producción en funcionamiento conocido, debería realizarse la implementación real en producción. de la feature branch antes de fusionarla en el master . La implementación desde la feature branch tiene mucho sentido, ya que en el caso de cualquier problema, la producción puede revertirse instantáneamente mediante la implementación del master . Por favor, eche un vistazo a una breve introducción visual de GitHub Flow.

GitLab Flow es una especie de extensión de GitHub Flow acompañada por un conjunto de https://docs.gitlab.com/ee/workflow/gitlab_flow.html que apuntan a estandarizar aún más el proceso. Además de promocionar listas para desplegar sucursales master y características (igual que GitHub Flow), introduce otras tres clases de ramas:

1. Rama de Production
2. Ramas medioambientales : uat , pre-production , production
3. Ramas de liberación : 1-5-stable , 1-6-stable

Creo que los nombres y ejemplos anteriores son autodescriptivos, por lo que no lo explicaré más.

Answer 2

GitLab Flow propone utilizar ramas master y feature también. Una vez que la función está hecha, la fusionamos de nuevo a la rama master . Esta parte se ve igual que en GitHub Flow .

Entonces, tengo entendido que nos dan 2 opciones sobre cómo hacerlo, dependiendo de si se trata de la aplicación SAAS o de la aplicación móvil (que se puede lanzar al mundo).

Si esta es la aplicación SAAS, usamos ramas de entorno, por ejemplo, pre-production y production . Estas sucursales se crean fuera del master cuando estamos listos para implementar nuestra aplicación. Tener diferentes sucursales por entorno nos permite configurar la herramienta CI / CD para implementar automáticamente los compromisos realizados en estas sucursales. Si hay un problema crítico, lo solucionamos en la feature o rama master y luego lo combinamos con environment ramas del environment .

En cuanto a las aplicaciones que pueden lanzarse al mundo (p. Ej., Aplicaciones móviles o de escritorio), entiendo que proponen utilizar un modelo diferente utilizando ramas de release lugar de ramas de entorno. Todavía hacemos todo el trabajo en las ramas de feature y las combinamos de nuevo a la rama master al finalizar. Luego, cuando nos aseguramos de que la rama master sea ​​lo suficientemente estable, es decir, que ya hayamos realizado todas las pruebas y correcciones de errores, creamos la rama de lanzamiento y lanzamos nuestro software. Si hay un problema crítico, primero lo solucionamos en la rama master y seleccionamos una solución para release rama.