Git tiene “Flow” - Blog Yunbit Software

Hoy vamos a hablar de control de versiones, y me diréis: ¿qué es esto y porqué debería importarme? El control de versiones es un sistema que registra los cambios realizados en uno o varios ficheros a lo largo del tiempo, pudiendo recuperarlos en el futuro e incluso ver quién los modificó.

Algunos de los sistemas de control de versiones más famosos son Subversion (también conocido como SVN) y GIT. En concreto vamos a hablar de GIT, un sistema desarrollado por el mismísimo Linus Torvals, también conocido como el padre del kernel de Linux.

A diferencia de SVN, GIT es un sistema de control de versiones distribuido, esto quiere decir que aún existiendo un repositorio central en el cual se incorporan los cambios, los usuarios pueden descargar una copia local teniendo acceso sin necesidad de conexión de red y pudiendo transferir los cambios al repositorio central de una manera rápida y eficaz.

Además de estas características, hay que destacar el gran trabajo que realiza Git a la hora de resolver conflictos, cosa que algunos sistemas no lo hacen nada bien, dándonos conflictos como si de EEUU y Corea del Norte se tratara.

Flujo de trabajo o metodología GIT-FLOW

Define la forma en la que gestionar las ramas de nuestro repositorio de Git para un equipo de desarrolladores.

A simple vista puede ser un poco lío, pero vamos a ver que no lo es tanto.

1. develop y master.

Estas dos ramas se crearán en el inicio del proyecto y no deberán ser eliminadas.

• master: En esta rama está el código fuente que está listo para ponerse en producción.
• develop: Esta es la rama que se utiliza para los últimos cambios en el desarrollo entregados y que se llevarán próximamente a la rama master.

Cuando los cambios en develop sean estables y estén listos para su puesta a producción, es cuando debemos realizar el merge con la rama master, etiquetando con un número de versión.

2. feature, release y hotfix

Estas ramas tienen un ciclo de vida muy corto. Se crean cuando se necesitan y se destruyen cuando se termina con ellas.

• feature: Ramas para la creación de nuevas funcionalidades. Es sacada de develop y cuando se termina el desarrollo se fusiona con la misma.
• release: Las ramas release se usarán para lanzar una nueva versión de nuestro proyecto, sólo para los últimos retoques antes de liberar la nueva versión. Se crearán a partir de la rama develop y se fusionarán tanto con master (para poder ser desplegadas en producción) como con develop.
• hotfix: Principalmente se usan para arreglar bugs que queremos que estén en producción lo antes posible.

Para facilitarnos el trabajo y evitar el uso de comandos tenemos a nuestra disposición un sin fin de herramientas, os recomiendo usar un cliente Git,  como puede ser SourceTree, que además de proporcionarnos un árbol visual de las ramas, nos da la opción de adaptar nuestro repositorio a GITFLOW de una manera rápida.

No podría faltar la mención a dos grandes imprescindibles en el mundo Git, como son Github y Bitbucket, lugares donde alojar nuestros proyectos Git con funcionalidades extra para su gestión.

Y para los que aún no habéis probado este sistema, os invito a que subais al carro. Y citando a  Charles Darwin:

“Las especies que sobreviven no son las más fuertes, ni las más rápidas, ni las más inteligentes; sino aquellas que se adaptan mejor al cambio”, y es que el ser humano tiende a acomodarse en lo conocido.