En esta oportunidad quiero hablar de una metodología para el uso de Git, llamada GitFlow
Luego de trabajar en una compañía 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 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 especifica. 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 grafico 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 produccion), esta rama no se toca y se suele llamar main, master o production. Contiene todo el codigo 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 esten 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.
Todo en minúsculas, por ejempo:
Supongamos que queremos agregar un botón nuevo en la pantalla principal de nuestra aplicación.
- Creamos una nueva rama que parte de develop y le anteponemos al nombre la palabra feature, indicando que es una nueva característica que queremos arreglar, quedando el nombre de la rama de la siguiente manera: feature/agregando-boton-pantalla-principal.
- En esta rama agregamos el codigo del nuevo botón y finalmente hacemos un Pull Request a Develop (en caso que en el equipo usen Pull Request) o directamente haces el merge a Develop.
- QA prueba este botón y cuando dan el “aprobado” entonces pasamos este desarrollo a producción, haciendo merge (unificando) la rama develop que ya tiene nuestro botón con la rama master.
Ahora supongamos que queremos arreglar el botón, porque por alguna razón nos quedó mal y QA tampoco se dio cuenta.
- De la rama develop, que a este punto ya tiene nuestro desarrollo, creamos otra rama y le anteponemos al nombre la palabra fix, quedando así fix/boton-pantalla-principal.
- Una vez terminado el desarrollo, el proceso siguiente es el mismo, primero a develop y cuando sea aprobado a master.
Con esto, logramos estandarizar todos los nombres de nuestra rama y al final del día, sabremos identificar fácilmente solamente por el nombre, qué contiene cada rama en nuestro repositorio git.
Para finalizar,
Comandos básicos de Gitflow
Te dejo una pequeña lista de los comandos que mas vas a usar para trabajar con gitflow:
Git checkout rama
Cambiamos la rama a la que hayamos indicado. Ejemplo, para cambiar a develop, Git checkout develop.
Git checkout -b rama
Crea una rama a partir de la rama en la que estemos situados.
Es parecido al comando anterior pero con el flag -b en vez de cambiarnos a una rama ya existente, primero crea una rama nueva con el nombre que le hayamos puesto y luego nos cambia a ella.
Git log
Muestra en pantalla el registro del repositorio que tenemos actualizado en nuestro equipo local. Super util para saber todos los commits que tiene la rama en la que estamos situados. Si usamos el flag —oneline nos da un resumen visual de este registro, ejemplo git log —oneline.
Git status
Este es un plus, porque si ya trabajas con git ya lo conoces, con este comando puedes ver el status de tu rama actual.
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 grafica 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 mas 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 grafica 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
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.
