Cinco Git Workflows para mejorar nuestros proyectos

Todos los desarrolladores hemos trabajado con diferentes flujos de trabajo Git. En este artículo se pondrá el foco en los diferentes aspectos que ofrecen las metodologías de trabajo actuales: introducción de cambios, resolución de conflictos, el uso de ramas, etc.

Cada equipo tiene su propio flujo de trabajo según el tipo de proyecto, el tamaño de la empresa y las preferencias del equipo, entre otras cosas. Cuanto más grande sea el equipo, más difícil será mantener todo bajo control: los problemas con los conflictos se vuelven más comunes, las fechas de lanzamiento deben posponerse, las prioridades se cambian sobre la marcha...
 
Emplear Git es el primer paso para resolver estos problemas, ya que se puede adaptar a prácticamente todo tipo de flujo de trabajo. Estos son los cinco tipos de flujo de trabajo Git que podemos utilizar en un proyecto.
 

 

Git Flow

Es el flujo de trabajo más popular y extendido. Se basa en dos ramas principales con una vida infinita. Para cada tarea que se le asigna a un desarrollador se crea una rama feature en la cual se llevará a cabo la tarea. Una vez que ha finalizado, realizará un pull request (validación) contra develop para que validen el código.

Pasamos a detallar las dos ramas principales que se utilizan:

• Master: Contiene el código de producción. Todo el código de desarrollo, a través del uso de releases, se mergea (fusiona) en esta rama en algún momento.
• Develop: Contiene código de pre-producción. Cuando un desarrollador finaliza su feature, lo mergea contra esta rama.

 
Durante el ciclo de desarrollo, se usan varios tipos de ramas para dar soporte:

• Feature: Por cada tarea que se realiza, se crea una nueva rama para trabajar en ella. Esta rama parte de develop.
• Hotfix: Parte de master. Rama encargada de corregir una incidencia crítica en producción.
• Releases: Parte de develop. Rama encargada de generar valor al producto o proyecto. Contiene el código que se desplegará, y una vez que se han probado las features integradas en la release, se "mergeará" a la rama master.

Pros

• Fácil de comprender el flujo de ramas.
• Ideal para productos estables que no requieren de desplegar cambios inmediatamente.
• Muy recomendable cuando el equipo tiene todo tipo de desarrolladores. El control de las features más la release hace que el código no se deteriore.
• Perfecto para productos open-source en los que pueden colaborar todo tipo de desarrolladores.

 

Contras

• No es el más indicado si tu proyecto necesita iterar muy rápido y subir a producción varias veces al día o semana.
• En caso de que el proyecto utilice varias herramientas de integración continua, la rama develop puede convertirse en una rama redundante de master.
• El uso de la rama master como rama protegida. Muchas herramientas de automatización usan la rama master por defecto.
• Gran complejidad en las ramas creadas de hotfix y releases. La integración continua elimina la necesidad de la creación de estas ramas, facilitando el despliegue.

 

 

GitHub Flow

La diferencia principal con GitFlow es la desaparición de la rama develop. Se basa en los siguientes principios:

• Todo lo que haya en la rama master debe ser desplegado.
• Para cualquier característica nueva, crearemos una rama de master, usando un nombre descriptivo.
• Debemos hacer commit en esta rama en local y hacer push con el mismo nombre en el server.
• Si necesitamos feedback, utilizaremos las herramientas de mergeo como pull request.
• Una vez revisado el código, podemos mergear contra master.
• Una vez mergeado contra master, debemos desplegar los cambios.

 

Pros

• Útil  y amigable con las actuales herramientas de CI/CC.
• Recomendado para features de duración corta (diarias o incluso de horas).
• Flujo ligero y recomendado si el proyecto requiere de una entrega de valor constante.

 

Contras

• Inestabilidad de master si no se utilizan las herramientas de testing/PR correctamente.
• No recomendado para múltiples entornos productivos.
• Dependiendo el producto, podemos tener restricciones de despliegues, sobre todo en aplicaciones SaaS.

 

GitLab Flow

GitLab Flow es una alternativa/extensión de GitHub Flow y Git Flow, que nace debido a las carencias que adoptan estos dos flujos. Mientras que una de las consignas de GitHub es que todo lo que haya en master es desplegado, hay ciertos casos en los que no es posible cumplirlo o no se necesita. Por ejemplo: aplicaciones iOS cuando pasan a la App Store Validation o incluso tener ventanas de despliegue por la naturaleza del cliente.

El flujo propone utilizar master, ramas features y ramas de entorno. Una vez que una feature está finalizada hacemos una merge request contra master. Una vez que master tiene varias features, llevamos a cabo una merge request a preproducción con el conjunto de features anteriores, que a su vez, son candidatas de pasar a producción haciendo otro merge request. De esta manera conseguimos que el código subido a producción sea muy estable, ya que validamos featues tanto a nivel individual como en lote.

La naturaleza de este flujo no requiere generar ramas de releases, ya que cada entorno será desplegado con cada merge request aceptada.
 

Pros

• Mucha confianza en la versión de producción.
• Ciclo de desarrollo muy seguro. Se revisa el código tanto a nivel individual en la feature, como a nivel global al pasar a preproducción o producción, mitigando el impacto.
• Previene el “overheap” de crear releases, taggings, merge a develop.

 

Contras

• Requiere de un equipo que valide las MR tanto de las features, como de los diferentes entornos.
• Tiempo demasiado alto para la entrega de valor. Desde que se crea y se valida la feature, hasta que llega a producción, tiene que pasar por muchas validaciones.
• Más complejo que GitHub Flow.

 

Trunk-based Flow

Este flujo es muy similar a GitHub Flow, con la característica nueva de las releases branch y el cambio de filosofía que presenta. Los principios que rigen este flujo son los siguientes:
 

• Los desarrolladores debemos colaborar siempre sobre el trunk (o master).
• Bajo ningún concepto debemos crear features branch utilizando documentación técnica. En caso de que la evolución sea compleja, haremos uso de features flags (condicionales en el código) para activar o desactivar la nueva carcterística.
• Preferiblemente usaremos la metodología Pair-Programming en vez de hacer uso de PR.

Se sacan ramas de release para poder desplegar el código en diferentes entornos, ya sea mobile, web, etc.
 

Pros

• Muy útil si nuestro  proyecto necesita iterar rápido y entregar valor lo antes posible.
• Responde muy bien a proyectos agile pequeños.
• Preparado para equipos que utilizan pair-programming.
• Funciona muy bien con un equipo experimentado y cerrado.

Contras

• Debemos ser responsables de nuestro código y hacer el esfuerzo de subir código de calidad.
• El proyecto debe tener QA y CD muy maduro, de lo contrario se introducirán muchos bugs en la rama trunk.
• No es recomendable utilizarlo en proyectos open-source, ya que requieren de una verificación extra de código.

 

Master-only Flow

El flujo de trabajo usa solo una rama infinita. Usaremos master en esta descripción, ya que probablemente sea el nombre más común y ya es una convención de Git, pero también puedes usar, por ejemplo, current, default, mainline, ...

Realizaremos cada feature o hotfix sobre la misma rama, testearemos y haremos commit en local. Una vez que este cambio se ha aprobado, haremos push contra master en origin, desplegándose en producción inmediatamente.

Este flujo está orientado a proyectos con desarrolladores muy experimentados y en el cual se fomente el pair-programming.

Debemos usar features-flags para poder integrar el código en la rama master y evitar conflictos a lo largo del tiempo.
 

Pros

• Solo mantenemos una rama.
• Tendremos el histórico del proyecto limpio.
• Con el uso de pair-programming y desarrolladores experimentados, la entrega de valor en producción es inmediata.

Contras

• No soporta múltiples entornos productivos.
• Requiere de desarrolladores experimentados para no dejar inestable la rama principal.
• El proyecto requiere de guidelines de código muy estrictas.