Una manera de usar git. Gestionando las ramas simulando Gitflow

Hola a tod@s 🤗. En esta entrada del blog voy a hablaros de Git. Para quien todavía no lo sepa, Git es un sistema de control de versiones distribuido. Pero no te voy a explicar cómo instalarlo ni qué ventajas tiene sobre otros sistemas como puede ser SVN. Puedes encontrar esto fácilmente en otros blogs. Esta es una entrada que escribo desde mi experiencia, como todas las que escribo, para mostrarte la manera en que gestiono yo mis proyecto con esta magnífica herramienta.

Perderse por las ramas en Git es fácil

¡No sé si te ha pasado ya!

Con Git es muy común y sencillo crear ramas para desarrollar las diferentes funcionalidades y versiones de nuestra aplicación. Sin embargo, esta facilidad para crear ramas puede llevar al repositorio al caos más absoluto si son creadas sin ningún criterio y sin ningún flujo de información detrás que las sustente.

CHISTE MALO. Como dicen en mi tierra: «No te andes por las ramas» 😂

Para que todos en un equipo sigamos una misma dirección a la hora de gestionar el código de cada proyecto, el paso de los años me ha llevado a identificar unas pautas y buenas prácticas a seguir basadas en GitFlow que te mostraré a continuación. Yo no he reinventado la rueda. No obstante, lo que aquí te explico puede (y debe) adaptarse dependiendo de las necesidades y particularidades de cada proyecto.

Flujo de trabajo general para el control de versiones

El flujo de trabajo que aquí defino es un flujo de trabajo general que puede ser adaptado en función de las necesidades y particularidades de cada proyecto.

La idea principal de este flujo es que el código de cada proyecto se organiza en base a dos ramas principales:

• master: cualquier commit que pongamos en esta rama debe estar preparado para subir a producción.
• dev: rama en la que está el código que conformará la siguiente versión planificada del proyecto.

Cada vez que se incorpora código a master, tendremos una nueva versión de nuestra aplicación.

Adicionalmente a estas ramas principales, en el ciclo de vida del proyecto jugaremos con las siguientes ramas auxiliares y no otras:

• feature
• release
• hotfix

Cada una de estas ramas tiene sus propias reglas, que intentaré resumir a continuación paso a paso.

Inicialización del repositorio

Para inicializar un repositorio ejecutaremos los siguientes comandos en un terminal:

git init
git commit --allow-empty -m "Initial commit"
git checkout -b dev master

Los comandos anteriores nos crearán un repositorio local con las ramas master y dev. Ahora podemos integrarlo con un repositorio remoto ejecutando:

git remote add origin https://server/namespace/project.git

El estado del repositorio debe ser como el que se muestra en la siguiente imagen:

Integrando una nueva funcionalidad en el proyecto

Los desarrollos de nuevas funcionalidades y bugfixes planificados se realizan sobre ramas feature:

Las reglas para estas ramas son:

• Normalmente, estas ramas existen únicamente en los repositorios locales de cada desarrollador aunque, si la funcionalidad se desarrolla entre varias personas, la rama puede existir en el repositorio remoto. También puede existir en el repositorio remoto como copia de seguridad si el desarrollo se prolonga por varios días.
• Siempre se originan a partir de la rama dev.
• Se incorporan siempre a la rama dev y solo cuando se dan por terminadas.
• Las nombraremos como feature/<issue_id>[-short_description], donde issue_id es el identificador de la incidencia del gestor de proyectos que usemos.

Los comandos para gestionar todo el ciclo son:

# Crear la rama a partir de dev
git checkout -b feature/<issue_id>[-short_description] dev

# Compartir la rama (en caso necesario)
git checkout feature/<issue_id>[-short_description]
git push origin feature/<issue_id>[-short_description]

# Finalizar una rama Feature
git checkout dev
git pull origin dev
git merge --no-ff feature/<issue_id>[-short_description]
git branch -d feature/<issue_id>[-short_description]
git push origin dev

# Si se compartió la rama en el servidor
git push origin :feature/<issue_id>[-short_description]

Es importante la opción --no-ff para que quede constancia en la rama dev de todos los commits que se hicieron en la rama feature.

‼️ También es importante recordar eliminar la rama una vez que ha sido incorporada a dev, tanto en local como en origin.

Release branches

Cuando ha llegado la hora de lanzar una nueva release, se crea una rama release.
El código de esta rama se debe desplegar en un entorno de test adecuado, se prueba y cualquier problema se soluciona directamente en dicha rama. Este proceso de prueba > bugfix > prueba >… se repite hasta que el código sea lo suficientemente bueno como para lanzarlo a los clientes.

Cuando finaliza la versión, la rama release se fusiona con master y dev, para asegurarnos de que cualquier cambio realizado no se pierda accidentalmente por un nuevo desarrollo.

Las normas de estas ramas son:

• Se originan a partir de la rama dev.
• Se incorporan a master y dev una vez que el código está probado y listo para la siguiente versión.
• Las nombraremos release/x.y.z
• Se etiqueta la rama master con la nueva versión.

Los comandos para gestionar todo el ciclo son:

# Crear la rama a partir de dev
git checkout -b release/x.y.z dev

# Compartir la rama (en caso necesario)
git checkout release/x.y.z
git push origin release/x.y.z

# Finalizar una rama Release
git checkout master
git pull origin master
git merge --no-ff release/x.y.z
git tag -a x.y.z
git checkout dev
git pull origin dev
git merge --no-ff release/x.y.z
git branch -d release/x.y.z
git push origin master
git push origin dev
git push origin --tags

# Si se compartió la rama
git push origin :release/x.y.z

‼️ Es importante recordar eliminar la rama una vez que ha sido incorporada a dev y master, tanto en local como en origin.

Hotfixes

Las ramas hotfix se utilizan para corregir fallos urgentes e imprevistos directamente del código de producción. Una vez corregido el código, los cambios son incorporados a las ramas master y dev:

Las normas para estas ramas son:

• La creación de estas ramas no está planificada.
• Se originan a partir de la rama master.
• Se incorporan a las ramas master y dev.
• Las nombraremos hotfix/<issue_id>[-short_description], donde issue_id es el identificador de la incidencia del gestor de proyectos que usemos.

Los comandos para gestionar todo el ciclo son:

# Crear la rama a partir de una versión de master
git checkout -b hotfix/x.y.z [commit-id]

# Finalizar una rama Hotfix
git checkout master
git pull origin master
git merge --no-ff hotfix/x.y.z
git tag -a x.y.z
git checkout dev
git pull origin dev
git merge --no-ff hotfix/x.y.z
git branch -d hotfix/x.y.z
git push origin master
git push origin dev
git push origin --tags

‼️ Es importante recordar eliminar la rama una vez que ha sido incorporada a dev y master, tanto en local como en origin.

Conclusión

Como ves, gestionar las ramas con Git puede ser una tarea fácil si en el equipo existe un flujo definido que todos conozcamos y sepamos cómo utilizar. Incluso este flujo puede valer para tus proyectos personales.

El que aquí te he explicado es el que yo suelo utilizar en mi trabajo y mis proyectos y está basado en Gitflow, pero eres libre de definir el flujo que mejor se adapte a ti y tu equipo. Y tú, ¿cuál usas?

Si no te ha quedado claro o tienes cualquier duda, no dudes en ponerte en contacto conmigo. Estaré encantado de ayudarte.