Como iniciar el GitFlow sin morir en el intento

Durante el ciclo de vida del proyecto, durante la planificación, desarrollo y puesta a producción el producto existe muchas interacciones y personas involucradas.

Sin embargo, los desarrolladores deben de cumplir un papel muy importante para la entrega del producto, en la actualidad existen muchos desarrollos empíricos en la que no cuentan con buenas practicas y que en el proceso de ensayo y error logran alcanzar un pequeño proceso que se ajusta a su realidad.

GitFlow

Es un flujo de trabajo basado en GIT diseñado para organizar todo el proceso de la integración continua.

¡Porque Implementarlo!

Aumenta la velocidad de entrega de código terminado al equipo de pruebas.
Disminuyen los errores humanos en la mezcla de las ramas.
Elimina la dependencia de funcionalidades al momento de entregar código para ser puesto en producción.

¿Cuando se recomienda implementarlo?

El equipo de trabajo está conformado por más de dos (2) personas.
Se emplean metodologías ágiles.
El proyecto tiene cambios frecuentes y se requiere actualizar el ambiente de producción garantizando continuidad en la operación.
El proyecto tiene un nivel de complejidad considerable.
Se desea tener un proceso de soporte a errores efectivo con actualizaciones rápidas.

Proceso de implementación

La definición de las ramas deben de ser bien definidas, para ello el estándar recomendado son los siguientes.

Ramas Principales:

master
develop

Otras Ramas:

feature: Rama para la creacion de nuevas o modificaciones funcionalidades del proyecto.
hotfix: Corrección de parches de bug en producción estas son solucionadas de manera rápida.
release: Desplegar la nueva funcionalidad en en producción lanzando nueva versión, esta va a pasar por pruebas.

bugfix: Correcciones de fallos que toman mas tiempo de lo debido y es fusionado con la rama master
support: Soporte de las funcionalidades y documentación de las mismas.

Plan de Inicio

En realidad, Gitflow es una especie de idea abstracta de un flujo de trabajo de Git. Esto quiere decir que ordena qué tipo de ramas se deben configurar y cómo fusionarlas. Explicaremos brevemente los objetivos de las ramas a continuación. El conjunto de herramientas de git-flow es una herramienta de línea de comandos propiamente dicha que tiene un proceso de instalación. El proceso de instalación de git-flow es sencillo. Los paquetes de git-flow están disponibles en varios sistemas operativos.

Se debe de instalar los paquetes, el proceso se encuentra en el siguiente link: https://danielkummer.github.io/git-flow-cheatsheet/

espués de instalar git-flow, puedes utilizarlo en tu proyecto ejecutando git flow init. Git-flow es un contenedor para Git. El comando git flow init es una prolongación del comando predeterminado git init y no cambia nada de tu repositorio aparte de crear ramas para ti.

Funcionamiento

Ramas principales y de desarrollo

El primer paso es complementar la rama main predeterminada con una rama develop. Una forma sencilla de hacerlo es que un desarrollador cree de forma local una rama develop vacía y la envíe al servidor:

git branch develop git push -u origin develop

Esta rama contendrá el historial completo del proyecto, mientras que main contendrá una versión abreviada. A continuación, otros desarrolladores deberían clonar el repositorio central y crear una rama de seguimiento para develop.

A la hora de utilizar la biblioteca de extensiones de git-flow, ejecutar git flow init en un repositorio existente creará la rama develop:

Ramas de función

Todas las funciones nuevas deben residir en su propia rama, que se puede enviar al repositorio central para copia de seguridad/colaboración. Sin embargo, en lugar de ramificarse de main, las ramas feature utilizan la rama develop como rama primaria. Cuando una función está terminada, se vuelve a fusionar en develop. Las funciones no deben interactuar nunca directamente con main

Ten en cuenta que las ramas feature combinadas con la rama develop conforman, a todos efectos, el flujo de trabajo de ramas de función. Sin embargo, el flujo de trabajo Gitflow no termina aquí.

Las ramas feature suelen crearse a partir de la última rama develop.

Creación de una rama de función

git flow feature start feature_branch

Sigue trabajando y utiliza Git como lo harías normalmente.

Publicacion en la rama remota

Cuando se haya realizado los commits de manera local se debe de publicar la rama en el remote con el siguiente comando:

git flow feature publish feature_branch

Finalización de una rama de función

Cuando hayas terminado con el trabajo de desarrollo en la función, el siguiente paso es fusionar feature_branch en develop.

git flow feature finish feature_branch

Ramas de publicación

Cuando develop haya adquirido suficientes funciones para una publicación (o se acerque una fecha de publicación predeterminada), debes bifurcar una rama release (o de publicación) a partir de develop. Al crear esta rama, se inicia el siguiente ciclo de publicación, por lo que no pueden añadirse nuevas funciones una vez pasado este punto (en esta rama solo deben producirse las soluciones de errores, la generación de documentación y otras tareas orientadas a la publicación). Cuando está lista para el lanzamiento, la rama release se fusiona en main y se etiqueta con un número de versión. Además, debería volver a fusionarse en develop, ya que esta podría haber progresado desde que se iniciara la publicación.

Crear ramas release es otra operación de ramificación sencilla. Al igual que las ramas feature, las ramas release se basan en la rama develop. Se puede crear una nueva rama release utilizando los siguientes métodos.

git checkout develop
git checkout -b release/0.1.0

En cuanto la publicación esté lista para su lanzamiento, se fusionará en las ramas main y develop, y luego se eliminará la rama release. Es importante volver a fusionarla en la rama develop porque podrían haberse añadido actualizaciones importantes a la rama release, y las funciones nuevas tienen que poder acceder a ellas. Si en tu organización se da mucha importancia a la revisión de código, este sería el lugar ideal para una solicitud de incorporación de cambios.

git checkout main
git merge release/0.1.0

Flujo General: Resumen

Se crea una rama develop a partir de main.
Se crea una rama release a partir de la develop.
Se crean ramas feature a partir de la develop.
Cuando se termina una rama feature, se fusiona en la rama develop.
Cuando la rama release está lista, se fusiona en las ramas develop y generar una petición de fusión a main.
Si se detecta un problema en main, se crea una rama hotfix a partir de main.
Una vez terminada la rama hotfix, esta se fusiona tanto en develop y genera una petición de fusión a main.