Mundo GitFlow: Introducción – Parte 1

Esta es una serie de artículos que haré sobre GitFlow, dado que el contenido es extenso e interesante. Siéntete como si fueses a disfrutar de una serie favorita en Netflix.

Había una vez (Sí, esto comienza a lo Disney) un señor llamado Vincent Driessen, cuyo ingenio nos trajo un modelo de desarrollo muy usado hoy en día a través del famoso control de versiones Git. ¿Por qué es my usado? Bueno, esto se debe a que GitFlow nos ofrece un sistema organizado para llevar el desarrollo de software.

Nos referimos al desarrollo de Software en esta historia, pero eso no significa que pueda utilizarse para otras cosas. Recuerda que Git es un control de versiones aplicado a cualquier clase de archivos.

Al crear un repositorio usando Git tendrás una rama principal llamada “Master”. Las ramas nos permiten  tomar el código que se encuentra en una rama principal (o cualquier otra rama origen que desees tomar) y jugar con el código para crear, arreglar o mejorar alguna cosa en el proyecto sin echar a perder el código que se encuentra en la rama principal.

GitFlow nos sugiere varias cosas:

Usar un repositorio central para el Proyecto

Es aquí donde Github, Gitlab, BitBucket, entre otros; hacen presencia. Los cambios que se deseen publicar (push) se harán en un repositorio central para que todos los involucrados en el desarrollo se mantengan al tanto de la situación:

La rama “Master” corresponde a Producción

No se puede jugar en esta rama. Aquí debe ir solamente el código que ya haya sido probado, probado y probado hasta que tenga el visto bueno de todos los involucrados.

Ya se lo que te preguntas: ¿En donde puedo desarrollar?

La rama “Develop” como rama de desarrollo

Esta es una rama especial que será el punto de encuentro de todos los desarrolladores con el código que deseen implementar. Se origina a partir de la rama “Master” al comienzo del proyecto y acá se incorporarán todos los desarrollos realizados.

Esta rama estará siempre en el repositorio junto con “Master” en toda la vida del proyecto y no podrá usarse para incluir código directamente. Estas dos ramas deben ser respetadas en este aspecto.

Teniendo en cuenta estas condiciones, llega la hora de explicar donde se puede jugar y echar a perder con gusto hasta lograr un resultado positivo..

La rama “Feature” como campo de juegos

Es aquí donde cada desarrollador responsable de una nueva funcionalidad podrá divertirse con ganas. Esta es una rama que se crea al momento de desarrollar algo nuevo que desee incorporarse en un futuro a producción. Se origina a partir de la rama “Develop”.

En este punto empieza la convención de nombres para las ramas nuevas. Las ramas “features” deben comenzar con una palabra o iniciales que las identifique, por ejemplo: “feature-home_responsive” o “ft-home_responsive”. El nombre dependerá del equipo de trabajo.

 

 

Una vez que se haya desarrollado y probado la funcionalidad, la misma puede incluirse en la rama “Develop”. Esto permite compartir tu nuevo desarrollo con el resto del equipo.

La rama “Release” como “Asegúrate que todo esté bien antes de salir”

Esta rama es especial, porque aquí se revisará a fondo todo el código y funcionalidades que se han incorporado anteriormente en develop para su puesta en producción. En una organización grande, el departamento de Calidad haría acto de presencia para revisar el proyecto en esta rama, porque nadie quiere que se incluya un error en producción, ¿verdad?

Esta rama puede recibir los commits que sean necesarios de acuerdo a la cantidad de correcciones que se realicen en esta fase. Es importante tomar en cuenta que, una vez decidido publicar esa nueva versión del proyecto, se debe hacer a la rama “Master” y también a la rama “Develop”, puesto que la rama de desarrollo debe estar al tanto de estos últimos cambios.

Ahora, ya que hemos mencionado los errores en producción..

La rama “Hotfix” como “Llama al 911”

Siempre habrán fallas que aparecen en algún momento determinado. Puedes saberlo a través del feedback que recibas de tus usuarios o los mismos desarrolladores del proyecto. Cuando esto ocurre y estás trabajando en este flujo de trabajo, se crea esta rama “hotfix” a partir de “Master”.

Esta rama recibirá todos los commits necesarios para corregir la falla y publicar los cambios lo más rápido posible. Una vez que los cambios estén listos para publicarse, se harán a la rama “Master” y a la rama “Develop” de igual forma como sucede con “Release”: Los cambios deben publicarse en ambas ramas para que todos los integrantes del equipo puedan visualizarlo en su desarrollo y repositorios.

A simple vista el flujo es bastante completo y organizado, puesto que ordena el desarrollo en distintas fases usando las ramas correspondientes y manteniendo las reglas y prioridades:

  1. La rama “Develop” se origina a partir de la rama “Master” al inicio del proyecto.
  2. No se puede trabajar en las ramas “Master” y “Develop” directamente.
  3. Las nuevas funcionalidades se deben crear en nuevas ramas usando una convención de nombres y a partir de la rama “Develop”.
  4. Cuando se desee publicar actualizaciones a producción, se debe crear una rama “Release” y revisar una vez más antes de publicar a “Master”.
  5. Al publicar cambios en “Master” (cambios que vengan de “release” o “hotfix”) estos cambios deben publicarse también en “Develop”.
  6. La rama “hotfix” es la única rama que puede crearse a partir de “Master” para la corrección de una falla que exista en producción. (Obviando “Develop” por la regla 1).

Aterrizando en la realidad un poco..

Cambiar un flujo de trabajo por otro no es nada fácil. Requiere de mucha disciplina y cooperación por parte de todo el equipo. Imagina que estás en un proyecto que acaba de adoptar este flujo de trabajo:

  • Cada desarrollador tendrá su propio repositorio clonado del repositorio central.
  • Cada quién estará realizando los commits en sus respectivas ramas y luego hará Push a la rama develop.
  • Es posible que varios colaboradores estén trabajando en una misma rama, por lo que no sabrás exactamente quién hará un push primero y te hará revisar tu trabajo nuevamente.

Afortunadamente, Git está pendiente de los cambios que ocurren tanto en el repositorio central (origen) como en tu repositorio local. Si hay algún cambio en el origen y haces un push, Git te indicará que estás atrasado por X commits y tendrás que descargar los cambios primero (pull) para ver si lo que han publicado en la rama no creará conflictos con tu desarrollo. ¡Oh! Esto crea otra sugerencia:

Siempre es recomendable hacer Pull de la rama donde estés trabajando para asegurarte que estás al día.

En el próximo episodio llevaremos este proceso a cabo utilizando solamente git.

Anuncios

Un comentario en “Mundo GitFlow: Introducción – Parte 1

  1. Pingback: Mundo GitFlow: Instalación – Parte 2 | Las Notas del Nerd

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s