En esta oportunidad quiero hablar de una metodología para el uso de Git, llamada GitFlow
Luego de trabajar en una compañía Colombiana dedicada 100% a la entrega de servicios basados en tecnología era increíble como después de años teniendo tantos desarrolladores, tener orden en los desarrollos y un control eficiente de ellos era como pedirle a un asiático que no coma arroz más nunca, es decir, imposible.
Incluso en algún momento, cuando se nos une un partner con otro pool de developers, esta vez Mexicanos, yo llegué a pensar que tendríamos luz y ¡vaya sorpresa!, tampoco tenían ni idea. Lo que me llevó a pensar que no es tan común como yo creía y me inspiré a crear esta mini guía.
Que es GitFLow
Creado por Vincent Driessen, Gitflow no es más que una forma de usar Git, más ordenada. Se entiende como un modelo alternativo de creación de ramas en Git en el que se utilizan ramas de función y varias ramas principales con el único objetivo de mantener siempre el código lo más aislado posible de las ramas donde trabajen más personas.
Esto ayuda a tener controlado los nuevos features o fixes que se van haciendo a un mismo sistema y cuyo código repose en un sistema git (puede ser bitbucket, gitlab o github, todo es lo mismo).
Aplicando gitflow en nuestros desarrollos podemos llegar a tener un mejor control de los cambios, lo que nos ayuda muchísimo a desplegar calidad. Sobre todo si en nuestra empresa estamos usando métodos agiles de desarrollo como scrum por ejemplo.
Requitos para Gitflow
Uno solo, saber las bases de Git.
Ramas de función
Se entiende como ramas de función a las ramas que vayamos creando que tengan una función específica. Por ejemplo, la rama de un servidor de producción tiene una única función que es almacenar el código que tiene que estar en producción.
Lo mismo si tenemos servidores de desarrollo donde haremos QA y nuestras ramas locales en donde estamos escribiendo código nuevo.
Cada rama debe tener una única función establecida, en el siguiente gráfico tenemos una de las distribuciones más conocidas y usadas. Recuerda que gitflow no es una regla inmutable, son solo una serie de recomendaciones para trabajar mejor y por ende, esto puedes ajustarlo a tus necesidades.
Si te das cuenta, en este caso estamos estableciendo ramas por la función en donde debe estar desplegada. Tenemos 3 lugares
Master (servidor de producción), esta rama no se toca y se suele llamar main, master o production. Contiene todo el código que el cliente finalmente recibe en su aplicación.
Develop (entornos de desarrollo, testing o demos), inicia como una copia de lo que tenemos en producción y es ella quien va a recibir los features y fixes que vamos desarrollando.
Una vez todos los desarrollos que queremos entregar estén listos, probados y certificados, esta rama se unifica con la rama Master
Features/Hotfix (local): Son las ramas que los desarrolladores van a ir creando en su local, estas ramas deben partir de la rama Develop y cuando el desarrollador culmine el entregable, se unifica nuevamente con la rama Develop.
Veámoslo ahora un poco más gráfico.
Notamos como de master sale develop y a su vez, de develop salen los features, una vez que el desarrollo está completado, se cumple nuevamente la misma ruta, pero al revés, primero se unifican todos los features a develop y luego a master.
Solo debemos tener 1 master, 1 develop, pero tanto los features como los fixes pueden ser todos los que sean necesarios.
Nuevamente, este es el texto original de como fue pensado, sin embargo, puedes adaptarlo a tu modelo de trabajo como gustes.
Tipificación de las ramas
El creador Vincent Driessen nos deja unos pequeños lineamientos para crear los nombres de estas ramas de función:
master, para la rama prinpcial
develop, para la rama que unifica todos los desarrollos
feature/nombre-desarrollo-corto, para las nuevas características.
fix/nombre-del-arreglo-del-bug, para las ramas que pretenden arreglar errores en nuestro sistema.
Aplicaciones para gitflow.
¿No se te dan las líneas de comando?, mi primera recomendación es que intentes dominar gitflow con línea de comandos, pero si aun así no te gusta, no te preocupes, existen aplicaciones gratuitas que te pueden ayudar incluso visualmente con esto, te dejo un par de ejemplos,
GitKraken
Fíjate que la misma gráfica que te expliqué más arriba, la aplicación te la entrega de forma vertical, donde la línea vertical de color azul celeste en el medio es nuestra rama master y a ella siempre terminan llegando todos los features (líneas hacia la derecha en diferentes colores).
Es la más visual de todas las herramientas actuales y es gratis siempre y cuando uses repositorios públicos, si quieres usar repos privados debes pagar.
Sourcetree
No tan visual como gitkraken, pero también entrega la misma gráfica con los cambios usando metodología gitflow donde todas las ramas apuntan a la rama master que esta situada a la izquierda, de color azul.
Esta si es gratis para todo lo que quieras usarla y es creada por la gente de Atlassian, los creadores de Bitbucket, una alternativa a Github.
Palabras finales
Debo comentarte que esta es la forma de usar gitflow por la vía manual, donde uno mismo crea las ramas, los nombres, etc…
Pero existe una extensión que puedes instalar a tu repositorio en el que con algunos comandos diferentes puedes hacer el mismo trabajo. Hay quien le parezca más fácil el método manual, pero hay otros que les parece más fácil usar la extensión git-flow.
Para ello, te dejo otro artículo de un blog amigo que te explica de forma fácil usar esta extensión
Manual (básico) de git-flow
Sin más, espero que te sirva en tu día a día esta guía y así como ya muchas personas me han contactado por mi artículo de “Instalar OCI en Laragon” me puedes contactar y seguramente te doy una manito.
Saludos y happy coding.
