Gitflow: Flujo de trabajo en Git

Trabajar en Git se puede volver complejo cuando hay mas de un desarrollador en el proyecto o cuando se tienen diferentes versiones de un mismo proyecto, para evitar estos problemas se recomienda tener un flujo de trabajo que permita controlar este tipo de situaciones.

Gitflow

Gitflow es un conjunto de recomendaciones para trabajar en Git, propone reglas para crear ramas y cómo se debe interactuar con ellas, fue propuesto originalmente por Vincent Driessen en su artículo A successful Git branching model y es aceptada ampliamente.

Gitflow esta basada en los conceptos de Ramas principales y Ramas de apoyo.

Ramas principales

Son las ramas que debe tener todo proyecto y deben ser creadas al inicio del desarrollo:

`master`	Rama para el código fuente del proyecto en producción.
`develop`	Rama para el código fuente en proceso de desarrollo.

Para estas ramas se deben tener las siguientes consideraciones:

La rama master debe tener la versión de producción o estable del proyecto.
Todas la tareas del equipo se debe ir integrando hacia la rama develop.
Sólo el responsable del proyecto debe tener permisos de escritura en la rama master.

Ramas de apoyo

Son ramas que se utilizan para trabajar nuevas funcionalidades, mejoras y correcciones.

`feature/`	Ramas para la creación de nuevas funcionalidades.
`release/`	Ramas para el lanzamiento de versiones programadas.
`bugfix/`	Ramas para la corrección de funcionalidades en desarrollo.
`hotfix/`	Ramas para la corrección de funcionalidades en producción.

Ramas feature

Estas ramas se usan para la implementación de nuevas funcionalidades o mejoras del proyecto.

Se crean desde la rama develop.
En estas ramas se implementan funcionalidades y mejoras.
Una vez terminada la tarea debe integrarse hacia la rama develop.
El nombre empieza con feature/, ejemplo: feature/formulario-contacto

Ramas release

Son ramas que sirven como preparativo para un lanzamiento o versión del proyecto, sobre esta rama se hacen las correcciones y pruebas antes de un lanzamiento.

Se crean desde la rama develop.
Una vez terminada la revisión debe integrarse hacia develop y a master.
El nombre empieza con release/, ejemplo: release/v1.0

Ramas bugfix

Son ramas que sirven para corrección de errores de funcionalidades que aún no están en producción.

Se desde la rama release.
Una vez terminada la corrección debe integrarse hacia release.
El nombre empieza con release, ejemplo: bugfix/soporte-para-ios

Ramas hotfix

Son ramas creadas para hacer correcciones urgentes de un proyecto en producción.

Se desde la rama master.
Son ramas que se deben atender inmediatamente por que son errores en producción.
Una vez terminada la corrección debe integrarse hacia master y develop.
El nombre empieza con hotfix, ejemplo: hotfix/error-en-certificado-ssl

Conclusiones

Siguiendo estas recomendaciones de trabajo es posible mantener ordenado un proyecto aún cuando la cantidad de tareas sea elevada o se tenga varios desarrolladores al mismo tiempo. Tener una nomenclatura de ramas definida permite identificar rápidamente al equipo el tipo de tareas y evita las confusiones.