Flujo de trabajo Centralizado

Es la forma más sencilla de comenzar con Git. Con este sistema, trabajas directamente en master/main.

Los nuevos tiempos están haciendo que tengamos cuidado con la terminología. Master (maestro) tiene una relación directa con Slave (esclavo) y por eso mismo la industria está cambiando este término a Main. Es un cambio a una cultura más inclusiva y abierta.

Tras este inciso, retomo la explicación. Este sistema es muy sencillo al trabajar sobre main en lugar de una rama y fusionarla con main cuando terminas.

¿Cuándo se usa?

Una de las razones principales de trabajar con ramas es que otra persona revise tu trabajo. Si no es necesario revisar el código, ese trabajo extra es innecesario. Y aquí es donde este flujo de trabajo encaja perfectamente.

Por ejemplo, puedo citar estos escenarios:

  • Cuando trabajas solo.
  • Cuando trabajas en un equipo pequeño y cada uno trabaja en una parte concreta y especializada. Uno trabaja en backend y otro en frontend.
  • Cuando optimizas la velocidad del equipo. Las revisiones de codigo son excelentes para mejorar la calidad antes de enviarlo a main, pero cada revisión supone un gasto: revisión (cambio de contexto, postergar a terminar una tarea, carga mental para ambas partes, etc.) y tiempo (espera para quien lo solicita y reasignación para quien lo revisa). A veces esas revisiones se convierten en una mera aprobación sin revisión.
  • Cuando inicias un nuevo proyecto. Estas tu solo y creas el scafolding (andamios) para un proyecto grande o cuando estas con una PoC (proof of concept)

Buenas prácticas

Tienen más sentido para un trabajo en equipo.

  • Rebase/Merge pequeños y con mucha frecuencia. Esto te obliga a bajar codigo y resolver conflictos continuamente, pero tendrás todo el codigo actualizado.
  • Inmediatamente deshacer commit accidentales (por ejemplo, con errores o incompletos) en local y en el remoto.
  • Por supuesto, crea ramas para tu trabajo en curso (asi dejas commit más pequeños con un stash) y sin política de revisión.

Flujo de trabajo Trunk-Based

Tambien conocido como Flujo de Trabajo Feature Branch.

Existen ciertos escenarios en los cuales esta es una buena opción.

Es también la base de los demás flujos de trabajo (más o menos con lo que os he contado antes se aplica al centralizado). Concretamente en los flujos Gitflow y Forking.

Dependiendo del equipo es posible que puedas adoptar una opción simple o bien adoptar la version más compleja. Por ejemplo, exigiendo al equipo que nombre las ramas con unas funciones determinadas, con prefijos.

El unico hándicap que veo es que el equipo debe estar altamente cualificado y en un entorno muy controlado: muchos test de todo tipo.

 

¿Cuándo se usa?

  • Cuando trabajamos en paralelo con funcionalidades.
  • Cuando es necesario una revisión.
  • Cuando se comparte codigo que está en desarrollo. Por ejemplo es necesario usar codigo de otra feature y no está disponible en main.
  • Cuando se colabora en una misma funcionalidad, cada persona tiene su rama, luego se fusiona en una y finalmente cuando se termina, se fusiona en main. De esta forma siempre tienes estable main.

Buenas prácticas

  • Limpiar continuamente ramas obsoletas.
  • No reutilizar ramas para obligarte a bajar la main cuando comiences una nueva funcionalidad. En teoria nunca deben existir ramas de larga duración.
  • Nunca realices un rebase de una rama publica; en vez de esto realiza merge de master a la rama, evitaras rescribir la historia.
  • Los test es parte obligatoria, sobre todo regresivo para estar seguros de que no se rompe nada.

Flujo de trabajo Gitflow

Ampliamente conocido pero que tiene ciertos sabores dependiendo de donde los apliques.

No es lo mismo un Gitflow de GitLabs, que uno de Atlasian, que uno de GitHub.

Os recomiendo este articulo de GitKraken. Podréis ver rápidamente los distintos sabores. Aunque fue Vincent Driessen en us articulo de 2010 quien lo presentó, en estos años la evolución y adaptación existe.

Como resumen, es una versión muy especializada del flujo de trabajo con ramas. Donde las reglas están muy definidas (ver la nota de Vicent de 2020). Viene a decir que Gitflow es un enfoque excelente pero que quizá un enfoque más simple en la actualidad es más eficiente en tu trabajo.

Muchas veces he entrado en proyectos con este enfoque que luego no valía para nada, solamente para enmarañar más el trabajo y sin reglas de bloqueos con main, he llegado a ver más problemas que beneficios.

Decide por ti mismo y cuidado con decidir: si todo el mundo lo hace yo también.

 

¿Cuándo se usa?

  • Si tu software tiene una versión explícita, especialmente si tienen en producción dos versiones. Por ejemplo, la 2.y.z pero deseas que se siga usando la versión 1.y.z
  • Si tu aplicación sigue un lanzamiento regular. Nos permite seguir trabajando mientras se prueba y estabiliza la versión.
  • Si el proyecto es grande y el equipo no es tan eficiente como quisieras.
  • Evítalo en modelos de implementación continua como un desarrollo web. Muchas veces esto sobrecarga de manera innecesaria al proyecto.

Buenas prácticas

  • Como la rama main es quien está en producción. Bloquéala con todas las políticas posibles. Igualmente para las ramas de larga duración, protegerlas lo máximo posible.
  • Las ramas de funcionalidades se integra en Dev, cuidado y usa políticas de nombre estrictas. Muchas veces no las he visto en Main. Y por tanto desastre.
  • Un hotfix tras mergearse en main, se mergea en development. Muchos errores fantasma se deben a olvidar esto.

Flujo de trabajo Forking

El flujo de trabajo de bifurcación, se usa para contribuir a un proyecto al que solo tienes acceso de lectura. Muchos grandes proyectos de GitHub funcionan así.

Cuando no tengas acceso, deberás enviar los cambios a una copia publica del proyecto. Esta copia publica y personal del proyecto, se llama fork (bifurcación). El repositorio original, o fuente, se conoce por convención como repositorio upstream (ascendente).

Para solicitar que el repositorio ascendente fusione una rama de su bifurcación, debes crear una pull request.

En este caso ya os he contado cuando se usa y tampoco puedo daros mejores prácticas por qué serían, en las ocasiones que he trabajo, las mismas que cuando trabajo solo, es decir, un modelo centralizado.