¿Git? ¿Git Flow? ¿Github Flow? ¿Trunk? ¿Ship?
¿Qué es Git?
En la programación se utilizan herramientas para respaldar los diferentes trabajos, entre estas, una de las más utilizadas es Git, que nos permite almacenar colecciones de archivos, directorios, metadatos, entre otros, a su vez, no solo el almacenamiento es su principal ventaja, también podemos contar con el historial de cambios y modificaciones.
Por otra parte, Git se puede conectar plataformas tipo servicios en línea para almacenar y alojar repositorios, mejorando el intercambio de código entre desarrolladores, además de contar como respaldo en la nube, en mi experiencia puedo destacar GitHub que es la plataforma que uso yo.
Además, Git emplea una estructura de ramas, que permite trabajar en paralelo en diferentes versiones de cada repositorio, habilitando fusiones entre las distintas ramas para incorporar cambios a la versión principal del proyecto, funcionalidad que ha permitido en primera instancia restaurar a versiones anteriores (en caso de haber agregado errores al trabajo), hasta controlar el flujo, orden, seguimiento y gestión de los proyectos.
¿Pero entonces que es Git Flow?
Bueno, digamos así como lo vimos anteriormente no es del todo suficiente para mantener un grupo de trabajo sincronizado y trabajando eficientemente sin pisarse la cola entre desarrolladores, ya que todo es perfectible, se han desarrollado algunas metodologías para poder administrar y gestionar los flujos, con una serie de reglas y pautas, en este caso propuestas por Vincent Driessen, siendo esta misma un tanto popular en la comunidad del desarrollo.
El enfoque Git Flow se basa en la idea de tener un flujo de trabajo estructurado y consistente, lo que facilita la colaboración entre los miembros del equipo y la administración de las versiones del proyecto. La metodología se basa en el uso de dos ramas principales: la rama “master” o “main” y la rama “develop”.
La rama “master” o “main” representa la rama principal del repositorio y se utiliza para almacenar la versión estable del software. Se supone que esta rama, a menudo, contiene el código lanzado a producción u operaciones.
La rama “develop” es donde se realiza el trabajo principal del proyecto. Esta rama se usa para integrar todas las nuevas características y cambios en desarrollo. A medida que se agregan nuevas características, se crean ramas de características a partir de la rama “develop”.
Además de estas dos ramas principales, Git Flow define otras ramas de carácter auxiliar que se emplean para distintos propósitos, entre estas puedo destacar “características”, “lanzamiento”, “corrección de errores”, entre otras.
Hasta el momento, el flujo de trabajo básico de Git Flow contempla que los desarrolladores deberán generar ramas de las respectivas funcionalidades en la que trabajan a partir de la rama “develop”, hagan su trabajo en esas mismas y luego las fusionen nuevamente en la rama “develop” una vez que la funcionalidad esté completa y probada, lo anterior, podría verse mejor ilustrado con el siguiente gráfico.
Por otra parte, tenemos a GitHub Flow
Si bien toda esa telaraña anterior puede ser algo confusa y que, por cierto, generó ya suficiente conflicto en algunos grupos de desarrolladores, los mismos desarrolladores de GitHub tomaron las riendas y presentaron su propia metodología para ordenar y administrar los repositorios.
Presentado en pocas palabras, en esta metodología tenemos la rama principal (Main o Master) a la cual se le generarán ramas dependiendo de la nueva “feature”, cuando esta nueva funcionalidad, esta lista, testeada y preparada, se procede con pull request directo a la rama principal.
Cabe destacar que en esta forma de trabajar no se hace diferencia entre un hotfix (reparación de un error) con una feature desarrollada… así de simple.
Trunk
Bueno, por otra parte, tenemos trunk based development, y es que esta metodología es una de las primeras en ser utilizadas, sin embargo, no tiene mucha ciencia de por medio, ya que, en aquellos tiempos, no se contaba con las tecnologías para generar diferentes ramas para cada característica, por lo que, principalmente se utiliza una sola rama principal (trunk o tronco).
Una vez con el proyecto se encuentre en la rama principal, se le irán efectuando los commits directamente y en respectivos casos, pull requests, aunque, claramente, cada empresa o célula de trabajo deberá considerar redes de seguridad para evitar un pase a producción con errores.
Imagino que cada trabajador tendrá su opinión respecto a una metodología tan directa, pero la verdad es que solo podremos saber si es una ventaja o no dependiendo de la magnitud del proyecto, ya que la verdad este tipo de workflows puede reducir bastante la fricción innecesaria de trabajos a baja escala.
Finalmente, tenemos Ship / Show / Ask
Y final finalmente, luego de haber explicado todas las metodologías anteriores (necesario para entender mejor esta), tenemos ship, show, ask… la cual básicamente es una mezcla de Trunk y GitHub Flow, sin embargo, es requerimiento tener una sólida cultura DevOps CI/CD.
En este caso, el pipeline siempre es recomendado que contenga algunas funcionalidades específicas.
- Revisión de código y prácticas (puede utilizarse SonarQube).
- Testing completo (Jest, Cypress, Jmeter).
- Guardado en repositorio de artefactos (hay muchos, yo he usado Nexus Repository).
- Si todo ha salido bien, realizar el auto, merge y notificar al equipo para esperar comentarios.
Claramente, el pipeline va haciéndose más complejo, agregando distintas funcionalidades, pero eso ya va en los requisitos de cada proyecto.
Algo de bibliografía
Flujo de GitHub — Documentación de GitHub
Estrategia de Git: Ship / Show / Ask (midu.dev)
Audiocurso de Frameworks y Arquitecturas Frontend: Casos de Estudio — Platzi
