Git es, con diferencia, el sistema de control de versiones moderno más utilizado del mundo. Git, que presenta una arquitectura distribuida, es un ejemplo de DVCS (sistema de control de versiones distribuido, por sus siglas en inglés). En lugar de tener un único espacio para todo el historial de versiones del software, como sucede de manera habitual en los sistemas de control de versiones antaño populares, como CVS o Subversion (también conocido como SVN), en Git, la copia de trabajo del código de cada desarrollador es también un repositorio que puede albergar el historial completo de todos los cambios.

GIT no tiene un flujo de trabajo oficial y definido. En el libro de GIT vienen algunos flujos sugeridos para trabajar con ramas y flujos de trabajo distribuidos pero no hay que seguir esos flujos obligatoriamente. Cada equipo puede elegir o crear uno que se adapte a sus necesidades y/o formas de desarrollar.

Tras años de experiencia con el uso de GIT se han ido definiendo algunas formas «normalizadas» de flujos según el tipo de proyecto. En este post vamos a profundizar en 3 de ellos.

Git Flow

Este flujo es uno de los más utilizados, sino el que más, por los equipos de desarrollo. Fue creado en 2010 por Vincent Driessen.

La base del flujo se sustenta sobre dos ramas:

• MASTER: Esta rama es la que se encuentra en el entorno de producción.
• DEVELOP: Es dónde se van incorporando todas las nuevas funcionalidades.

Durante el ciclo de desarrollo se trabaja con ramas con una nomenclatura ya establecida:

• feature/* Ramas con nuevas funcionalidades. Se crean desde DEVELOP.
• hotfix/* Ramas de arreglo de bugs. Se crean desde MASTER.
• release/* Ramas con una versión candidata a pasarse a MASTER. Se crea desde DEVELOP.

Ventajas:

• Asegura un estado estable en las ramas del proyecto en cualquier momento del desarrollo.
• Estandarización de nombres de ramas.
• Existen extensiones para la gran mayoría de clientes GIT.
• Ideal para tener múltiples versiones en producción al tener el concepto de ramas RELEASE.

Desventajas:

• El historial es difícil de entender. Hay demasiados merges no necesarios.
• La rama MASTER es redundante de DEVELOP, ya que DEVELOP siempre contiene MASTER, por lo que se podría prescindir de MASTER.
• No es recomendable para mantener una sola versión en producción. Para ello es necesario mergear la release abierta an MASTER antes de lanzar una nueva.
• No es muy amigable de CD ya que si se despliegan RELEASES hay que controlar cuál va a cada entorno y si es MASTER la que se despliegan vienen muchos cambios al mismo tiempo desde la release actual y se despliean todos al mismo tiempo.

GitHub Flow

Este flujo fue creado por GitHub en 2011 y ajustado posteriormente hasta el flujo actual

Las reglas básicas son las siguientes:

• MASTER es el source of truth. Es el historial de todos los desarrollos desplegados correctamente. La rama que más tiempo tiene que estar en producción.
• Las ramas de desarrollo de nuevas funcionalidades o fixes salen desde MASTER.
• Una vez finalizado el desarollo se crea una pull request dónde los revisores dan el ok para subirlo a producción/pre/staging o dónde se decida.
• Una vez testeado, esa pull request se pasa a master y se sube a producción.

Ventajas:

• Es amigable con CI y CD.
• Ideal para una sola versión en producción.
• Historial simple.
• Fácil rollback si algo no va bien.

Desventajas:

• Más susceptible a inestabilidad de código.
• No adecuado para trabajar con releases.
• No recomendado para varias versiones en producción.
• Para el CI y CD es necesario tener bien configurado una herramienta que gestione MASTER, las ramas de desarrollo, los entornos y los rollbacks.

GitLab Flow

Este flujo fue creado por GitLab en 2014. Combina el desarrollo basado en funcionalidades y ramas de funcionalidades con seguimiento de issues. La mayor diferencia con GitHub Flow son el nombre de la ramas que usa GitLab (staging y production) porque puede ser que no todo lo que llega a producción se despliegue automáticamente.

Se basa en 11 reglas:

1. Usa ramas de funcionalidades. No se commitea directamente en MASTER.
2. Se testean todos los commits, no sólo los de MASTER.
3. Se pasan todos los tests en cada commit.
4. Se revisa el código antes de incorporarlo a la rama de producción.
5. Se despliega automáticamente en función de ramas o tags.
6. Los tags los añaden los usuarios, no un CI.
7. Las releases están basadas en tags.
8. Nuca se hace un rebase de los commits pusheados.
9. Todos sale de la rama principal y vuelve a ella.
10. Primero se arreglan los errores en la rama principal y después se pasa a las demás.
11. Los mensajes de confirmación reflejan la intención.

Ventajas:

• Compatible con CI y CD.
• El historial del repositorio es más limpio.
• Ideal para cuando necesitas una sola versión en producción.

Desventajas:

• Es más complejo que GitHub Flow.
• Si hay que mantener varias versiones en producción se puede volver igual de complejo que Git Flow.

Conclusión

Estos tres flujos son de los más conocidos, pero eso no quiere decir que los equipos deban seguir uno de ellos obligatoriamente. Cada proyecto es diferente, depende del tipo de software que se esté creando (web, apps móviles, apps de escritorio, …) y del número de componentes que forman el equipo, por lo que puede que incluso ninguno de estos flujos se adapte a las necesidades del proyecto. Ahí entra la flexibilidad de GIT que nos permitirá fijar el flujo de trabajo de nuestro equipo.

Aparte de estos tres flujos hay algunos otros estandars:

• OneFlow.
• Release Flow de Microsoft Azure.
• Trunk Based Development.
• Master-Only flow.