Cuatro flujos de trabajo para Git

Creado miércoles 14 septiembre 2022

En este artículo, se abordarán cuatro flujos de trabajo más populares entre los usuarios de Git, para que, de este modo, pueda decidir cuál se ajusta mejor a su propio ciclo de desarrollo.

Importante: Cabe destacar que, debido a las repercusiones del movimiento #BlackLivesMatter, GitHub ha sustituido algunas palabras utilizadas en su plataforma que pudieran relacionarse de alguna forma con una manifestación de racismo. Palabras como master, whitelist, blacklist y slave se encuentran en este proceso de cambio. Pero el más importante en ese momento y el cual ha empezado a tener efecto inmediato es que la rama master ahora se llamará main. Para mayor información léase el artículo: Why GitHub renamed its master branch to main.

Git Flow

Git Flow es el flujo de trabajo más conocido de este listado. Fue creado por Vincent Driessen en 2010 y está basado principalmente en dos ramas con un ciclo de vida infinito:

  • main / master — esta rama contiene el código de producción. Todo el código de desarrollo se fusiona con la rama main / master en algún momento.
  • develop — esta rama contiene el código de preproducción. Cuando las características están terminadas, entonces se fusionan con la rama develop.

Durante el ciclo de desarrollo, se utilizan diversas ramas de apoyo:

  • feature-* — las ramas feature se utilizan para desarrollar nuevas características previstas para las próximas versiones. Pueden derivarse de la rama develop y deben fusionarse exclusivamente con esta última.
  • hotfix-* — las ramas hotfix son necesarias para actuar inmediatamente ante un estado no deseado en la rama main / master. Puede ramificarse desde main / master y debe fusionarse con main / master y hacia develop.
  • release-* — las ramas release apoyan la preparación de una nueva versión de producción. Permiten arreglar muchos errores menores y preparar los metadatos para una distribución. Pueden derivarse de develop y deben fusionarse con main / master y develop.

Ventajas

  • Garantiza un estado limpio de las ramas en cualquier momento del ciclo de vida del proyecto.
  • La nomenclatura de las ramas sigue un patrón sistemático que facilita su comprensión.
  • Cuenta con extensiones y soporte para las herramientas git más utilizadas.
  • Es ideal cuando se necesita tener múltiples versiones en producción.

Desventajas

  • El historial de Git se vuelve ilegible.
  • La separación entre main / master y develop se considera redundante y dificulta la liberación e integración continua.
  • No resulta ser recomendable cuando se necesita mantener una única versión en producción.

GitHub Flow

GitHub Flow es un flujo de trabajo ligero. Fue creado por GitHub en 2011 y respeta los siguientes 6 principios:

  1. Cualquier cosa en la rama main / master es desplegable («deployable»).
  2. Para trabajar en alguna característica nueva, cree una rama a partir de main / master y dele un nombre descriptivo (por ejemplo: new-oauth2-scopes).
  3. Confirme («commit») en dicha rama localmente y envíe regularmente su trabajo a la rama con el mismo nombre en el servidor.
  4. Cuando necesite retroalimentación, ayuda, o considere que la funcionalidad se encuentra lista para ser fusionada, abra una solicitud de inserción («pull request»).
  5. Después de que otra persona haya revisado y aprobado la característica, puede fusionarla en main / master.
  6. Una vez que se ha fusionado y enviado a main / master, puede y debe implementarse («deploy») inmediatamente.

Ventajas

  • Resulta ser amigable con el proceso de liberación e integración continua.
  • Una alternativa más simple que Git Flow.
  • Es ideal cuando se necesita mantener una única versión en producción.

Desventajas

  • El código de producción puede volverse inestable muy fácilmente.
  • No resulta ser adecuado cuando se requiere de planificación antes de la liberación de una nueva versión.
  • No resuelve ninguna aspecto sobre la implementación, los entornos, las versiones y la solución de problemas.
  • No resulta ser recomendable cuando se necesitan varias versiones en producción.

GitLab Flow

GitLab Flow es un flujo de trabajo creado por GitLab en 2014. Combina el desarrollo basado en funcionalidades, brindando un papel protagónico a las ramas feature con seguimiento de problemas («issue tracking»). La mayor diferencia entre GitLab Flow y GitHub Flow son las ramas de entorno sugeridas por GitLab Flow (por ejemplo, staging y production) dado que podría existir algún proyecto que no sea capaz de implementarse («deploy») a producción cada vez que se fusione una rama feature (por ejemplo, aplicaciones SaaS y aplicaciones móviles).

GitLab Flow se basa en 11 reglas:

  1. Utilizar ramas feature, sin «commits» directos a main / master.
  2. Probar todos los «commits», no sólo los que se encuentren en la rama main / master.
  3. Ejecute todas las pruebas en todos los «commits» (si sus pruebas duran más de 5 minutos, hágalas correr en paralelo).
  4. Realice revisiones de código antes de realizar las fusiones en la rama main / master, no después de ello.
  5. Las implementaciones son automáticas, basadas en ramas o etiquetas.
  6. Las etiquetas son establecidas por el usuario, no por la IC.
  7. Los lanzamientos se basan en etiquetas.
  8. Los «pushed commits» nunca se rebasan.
  9. Todos parten de la rama main / master, y tienen como objetivo la rama main / master.
  10. Arreglar primero los errores en la rama main / master y después en la rama de lanzamiento.
  11. Los «commit messages» reflejan la intención.

Ventajas

Desventajas

  • Es más complejo que GitHub Flow.
  • Puede volverse tan complejo como Git Flow cuando necesita mantener múltiples versiones en producción.

One Flow

One Flow es una alternativa propuesta en el artículo GitFlow considered harmful, escrito en 2015, por Adam Ruka. La principal condición que hay que cumplir para utilizar One Flow es que cada nueva versión de producción se basa en la versión anterior. La mayor diferencia entre One Flow y Git Flow es la inexistencia de la rama develop.

Ventajas

Desventajas

  • No se recomienda para proyectos con liberación e integración continua.
  • La incorporación de las ramas feature dificultan la integración continua.


Referencias


TODO

@TODO

  • Revisar traducción general del documento.
  • Traducir el artículo «Why squash git commits for pull requests?»