Mejora el flujo de trabajo en tus proyectos con Gitflow

Usar Git y GitHub de forma correcta y organizada puede lograr que el desarrollo de nuestro producto se convierta en un proceso más profesional y menos doloroso. En este artículo conoceremos uno de los métodos más usados y populares para lograrlo: Gitflow. Este modelo de trabajo es sólo uno de los muchos existentes; y no es estrictamente necesario que se adopte al 100%. Consiste en el uso continuo de branches (o ramas) e issues para lograr hacer cosas tan simples como mantener el código libre de errores o hasta implementar sistemas de integración para automatizar nuestro _deployment _y/o testing. Si quieres aprender más acerca de esto y convertirte en todo un experto, te recomiendo tomar el Curso Profesional de Git y Github que tenemos en Platzi.

Ramas principales

Comenzaremos con las ramas master y **develop, **que serán nuestras guías durante todo el desarrollo de manera permanente. La rama master es aquella que siempre usamos por default cuando iniciamos un proyecto en Git o Github. Su regla principal consiste en que, en lugar de tener todo tipo de código, sólo contendrá el que ya está listo para producción; y nada más. Pensemos que todo el código que esté aquí, en cualquiera de sus versiones debe estar listo para ser lanzado en cualquier momento. Por otro lado, la rama develop contiene código con los nuevos desarrollos y características que se incorporarán en el próximo release. Por esta razón es también conocida como la rama de integración. En el momento en el que todo su código esté listo para producción y se ha probado lo suficiente, podremos integrarlo a **master. **

Ramas secundarias

A diferencia de las ramas primarias, estas no tienen un tiempo de vida perpetuo. Sólo funcionan como apoyo mientras escribimos código que aún no puede ser integrado a develop y, mucho menos, a master. Es importante mencionar que, en cuanto este código sea integrado a **develop, **esta rama deberá dejar de existir. En este caso, nos enfrentamos a diversas situaciones: podemos estar en el inicio del desarrollo de un nuevo feature, en el punto en el que estamos preparando código para ser liberado o en el caso en el que tenemos que corregir código de manera imprevista y rápida para corregir un bug. A continuación explicaré qué pasa en cada caso:

Desarrollando una nuevo feature

Las ramas de features suelen derivarse de develop y, una vez que estén listas, deberán ser incorporadas de  regreso a develop. La vida de este branch dura tanto como dure el desarrollo y sólo deben vivir en los repositorios de los developers y nunca en origin. Son útiles porque una nueva característica no tiene que ser integrada necesariamente a develop. Esto depende de la utilidad y necesidad de la misma.

Liberando una nueva versión

Las ramas de release deben ser ramas creadas a partir de develop con el único fin de agregar últimos detalles al código, corregir algunos fallos menores y agregar **meta-data **como versiones o autores. Una vez que esta rama cumple su objetivo, debe ser integrada a master y a develop de nuevo.

Salvando a nuestros usuarios

Las ramas de hotfix son aquellas que sirven para resolver bugs de último momento que de alguna manera inesperada pasaron a producción sin ser probadas. Estos parches deben ser un derivado de **master **y deben incorporarse de regreso; así como a develop. Como mencioné anteriormente, este modelo de trabajo no es el único que existe; pero es de los más útiles y sencillos de comprender. Si quieres aprender cómo funciona y empezar a implementarlo en tus proyectos, te recomiendo registrarte al curso de Git y GitHub en Platzi.