Todos los proyectos de desarrollo, así como los equipos de colaboradores, son distintos entre sí. Las necesidades de entregas y revisiones son distintas. Sin embargo, hay algo que en cualquier caso se requiere: la necesidad de mantener todo ordenado y versionado, sin que esto entorpezca la calidad del proyecto o la agilidad del equipo. Aquí quiero presentar algunas estrategias de trabajo en Git que pueden ayudar a los equipos.

Antes de entrar en detalle, dejemos claro que los sistemas de versionado de código en general permiten:

• Llevar versiones de cada cambio que realizamos a nuestro código
• Compartir con nuestro equipo dicho código y versiones
• Mezclar cambios
• Revisar cambios
• Obtener una copia de una versión específica
• Deshacer cambios
• Etiquetar
• Etc.

Características

• Algunos son de tipo centralizado (svn, cvs, etc)
• Otros son de tipo distribuido (Git, Mercurial, etc)

Como podemos ver, son fundamentales en el proceso de desarrollo.

Como ya comenté, hoy nos centraremos en Git. Este potente motor de versionado de código es tan flexible que nos permite optar por distintos flujos o estrategias de trabajo, elegir aquella que mejor se adapte a las necesidades a cubrir, e incluso armar nuestra propia estrategia.

Las necesidades del proyecto que estemos abordando con nuestro equipo y nuestra experiencia nos permitirán optar por algunas de las estrategias que mencionaré a continuación.

Git Flow

Es un flujo pensado para aquellos proyectos que tienen entregables y ciclos de desarrollo bien definidos. Está basado en dos grandes ramas con infinito tiempo de vida (ramas main y develop) y varias ramas de apoyo, unas orientadas al desarrollo de nuevas funcionalidades (feature), otras al arreglo de errores (hotfix) y otras orientadas a la preparación de nuevas versiones de producción (release).

GitHub Flow

Es la forma de trabajo sugerida por las funcionalidades propias de GitHub. Está centrado en un modelo de desarrollo iterativo y de despliegue constante.

• Todo lo que está en la rama main está listo para ser puesto en producción.
• Para trabajar en algo nuevo, se debe crear una nueva rama a partir de la rama main, con un nombre descriptivo. El trabajo se irá integrando sobre esa rama en local y, regularmente, también a esa rama en el servidor.
• Cuando se necesite ayuda o información o cuando la rama está lista para integrarla en la rama main, se debe abrir una pull request (solicitud de integración de cambios).
• El encargado de proyecto debe revisar y visar los cambios para fusionarlos con la rama main.
• Los cambios integrados se pueden poner en producción.

Para una detallada explicación pueden visitar el siguiente enlace en GitHub.

Gitlab Flow

Para brindar un mayor control, GitLab Flow añade a la estrategia anterior más ramas. Podemos tener branches por ambientes, QA, Producción y por Release (versión).

One Flow

En este flujo, cada nueva versión de producción está basada en la versión previa de producción. La mayor diferencia entre One Flow y Git Flow radica en que el primero no tiene rama de desarrollo.

Trunk Based Development

Aquí el objetivo buscado es el de realizar commit cortos, continuos, funcionales; evitando conflictos por merges grandes y teniendo siempre una versión lista para ser publicada. Esta estrategia es la más recomendada para equipos que implementan DevOps.

Conclusión

Me gustaría cerrar resaltando que Git es una herramienta muy potente para nuestro trabajo colaborativo diario. Y que el versionado de código permite no solo versionar código fuente de aplicaciones, sino también infraestructura. Esto lo convierte en el corazón de los equipos ágiles que implementan DevOps en sus proyectos y en la cultura de su organización.

Si prefieres verlo en video, te dejo un enlace al webinar que di sobre el tema: Flujos / Estrategias de trabajo con Git