Instalación y Uso de Git-Flow

Git-Flow es un conjunto de extensiones para Git que proveen comandos con un alto nivel de abstracción para operar repositorios basados en el modelo de ramificaciones propuesto por Vincent Driessen.

Prerrequisitos

Antes de realizar la instalación de los paquetes de git-flow debemos resolver las dependencia para ello instalaremos el paquete de 'Options Parsing Tool library'. Esta es una biblioteca de subrutinas que facilita la entrada de parámetros a un programa escrito en C. Los parámetros se analizan de forma fácil desde una línea de comandos, archivos de opciones, cadenas de texto de un entorno (environment) o desde un entorno interactivo. Para instalar la biblioteca utilizaremos la siguiente instrucción:

# apt-get  install  opt

Compilación e instalación

Con las dependencias resueltas procedemos a realizar la instalación, para ello descargaremos los fuentes desde la cuenta github del proyecto y realizaremos los siguientes pasos en la maquinas clientes (computadoras de los desarrolladores) en las cuales previamente tenemos que tener instalado git, consulte la entrada Instalación de Servidor Git usando el Código Fuente para más detalles.

$ git  clone  --recursive  git://github.com/nvie/gitflow.git
$ make  prefix=/usr  install

Entendiendo Git-Flow

Ahora que hemos realizado la instalación entendamos un poco la filosofía detrás de este modelo de versionado. En pocas palabras Git-Flow explota las características no lineal y lo económico que resulta las creaciones de ramas (branches) en el software de control de versiones Git, proveyendo una interfaz muy simple en cuanto a su uso pero muy poderosa.

Es importante hacer notar que todo lo que podemos hacer con este modelo se puede lograr con varios comandos de Git, pero Git-Flow nos asegura que se ejecuten todos los pasos en el orden adecuado, que se usen las ramas correctamente y que etiquetemos cuando se deba.

Esta estrategia de ramificación utiliza dos branches principales (master y develop) y varias ramas de soporte (feature, release, hotfix y support) que a diferencia de las ramas principales, estas últimas siempre tienen un tiempo de vida limitado, ya que serán eliminadas eventualmente. Cada una de estas ramas, tienen sus propias reglas, que resumiremos a continuación:

• master: es una de las dos ramas principales que perduran durante todo el ciclo de vida del gestor de versiones (nunca se destruye) y contiene las versiones congeladas de nuestros desarrollos listos para ser subidos al ambiente de producción. Sobre esta rama no se deben realizar commit, unicamente se recomienda realizar merge desde una de las ramas de soporte, esto con el fin de evitar a toda costa tener conflictos en ella. La razón de que existe esta regla es porque la rama master contiene el software que se ejecuta en producción y debe estar libre de errores, además de ser esta la rama que utilizamos en programas de integración continua. Debemos recordar que cada vez que incorporamos códigos a master, obtenemos una nueva versión "congelada".
• develop: es la otra rama principal de modelo y tampoco se elimina, se origina de la rama master y contiene el código que conformará la siguiente versión planificada de nuestro proyecto. Sobre esta rama tampoco se deben realizar commit de forma directa, solo se deben realizar merge desde una de las ramas de soporte. En develop se van resolver los conflictos provocados por el desarrollo de nuestro proyecto.
• feature: es una de las ramas de soporte más importantes y de mayor volatilidad. Se originan de la rama develop y se utilizan para desarrollar nuevas características de la aplicación que, una vez terminadas, se incorporan de nuevo a la rama develop con un merge o se descartan eliminando la rama. Por lo general se tiende a que esta rama exista en las máquinas de los desarrolladores y no el repositorio centralizado (origin).
• release: esta rama de soporte se origina de la rama develop y se utiliza para preparar el siguiente código en producción haciendo las correcciones menores de última hora y los últimos ajustes en los metadatos (e.g. modificar los archivos CHANGELOG y/o VERSION) antes de pasar el código a la rama master. Una vez terminados los cambios en esta rama las modificaciones se incorporan a las ramas develop y master.
• hotfix: es otra rama de soporte originada a partir de master y se utilizan para corregir errores y bugs en el código de producción. Su función es parecida a las ramas releases, siendo la principal diferencia que los hotfixes no se planifican. Concluido los cambios en esta rama se deben incorporar a las ramas master y develop.
  Puede haber una excepción a la regla, y es que, cuando existe una rama de release en uso y aún no se haya cerrado, los cambios de la rama hotfix deben combinarse en la rama de release abierta, en lugar de la rama develop. Al hacer esto eventualmente resultará también en la fusión de los cambios en la rama develop cuando se cierre la rama de release.
• support: esta es la rama menos esencial de la estrategia y para muchos clientes aún esta en una etapa inestable. Se originan a partir de una etiqueta especifica de la rama master y son utilizadas para mantener a la vez múltiples versiones de un proyecto. La idea principal es que trataremos a este branch de la misma manera que tratamos la rama de hotfix en la que arreglaremos el problema pero con la diferencia de que luego se incorpora de nuevo en el master.

Todas estas reglas antes expuestas surgen como una práctica recomendada cuando tenemos un proyecto que es desarrollado en paralelo por un grupo de personas. La flexibilidad de esta estrategia no obliga a seguirla al pie de la letra, por el contrario, se puede adaptar a las necesidades del proyecto o del equipo de desarrolladores. Por ejemplo si el código es mantenido/desarrollado por a lo sumo dos personas manejar todas estas ramas sería complejo e innecesario por lo que se recomienda para este caso en particular trabajar únicamente con las dos ramas principales. También sería innecesario mantener la rama support si en todo momento manejamos en producción una sola versión del código.

Instrucciones del flujo de trabajo

Veamos las instrucciones en Git-Flow y en Git nativo que nos permiten llevar a cabo esta estrategia de versionado:

Iniciar con el proyecto

Git/Git-Flow

# Nuevo  repositorio
$ git  init

# Clonar  un  repositorio  existente
$ git  clone  git@server.name:repo.git

Inicio de la rama de desarrollo (Develop)

Git

# Crear  una  nueva  rama  (desde  la  rama  master)
$ git  branch  develop

# Movernos  a  la  nueva  rama  recién  creada
$ git  checkout  develop

# De forma resumida las dos instrucciones anteriores se pueden simplificar en la siguiente:
$ git  checkout  -b  develop  master

Git-Flow

$ git  flow  init

Inicio de la rama de característica (Feature/*)

Git

# Creación de la rama característica desde la rama develop
$ git  checkout  -b  feature/carpe-diem  develop

# Terminar con la rama de caracterínstica
$  git  checkout  develop
$  git  merge  --no-ff  feature/carpe-diem
$  git  branch  -d  feature/carpe-diem
$  git  push  origin  develop    (*)

Git-Flow

# Creación de la rama característica
$ git  flow  feature  start  carpe-diem

# Terminar con la rama de característica
$ git  flow  feature  finish  carpe-diem

Inicio de la rama de publicación (Release/<version>)

Git

# Creaci&oaute;n de la rama publicación desde la rama de desarrollo
$ git  checkout  -b  release/v2.3.0  develop

# Terminar con la rama de publicación
$  git  checkout  master
$  git  merge  --no-ff  release/v2.3.0
$  git  tag  -a  v2.3.0

$  git  checkout  develop
$  git  merge  --no-ff  release/v2.3.0
$  git  branch  -d  release/v2.3.0

$  git  push  origin  develop    (*)
$  git  push  origin  master    (*)

Git-Flow

# Creación de la rama publicación
$ git  flow  release  start  v2.3.0

# Terminar con la rama de publicación
$ git  flow  release  finish  v2.3.0

Inicio de la rama para arreglos menores (Hotfix/<version>)

Git

# Creación de la rama arreglos desde la rama master
$ git  checkout  -b  hotfix/v2.3.7  master

# Terminar con la rama de arreglos menores
$  git  checkout  master
$  git  merge  --no-ff  hotfix/v2.3.7
$  git  tag  -a  v2.3.7

$  git  checkout  develop
$  git  merge  --no-ff  hotfix/v2.3.7
$  git  branch  -d  hotfix/v2.3.7

$  git  push  origin  develop    (*)
$  git  push  origin  master    (*)

Git-Flow

# Creación de la rama para cambios menores
$ git  flow  hotfix  start  v2.3.7

# Terminar con la rama de cambios menores
$ git  flow  hotfix  finish  v2.3.7

Inicio de la rama se soporte (Support/<version>)

Git

# Creaciónn de la rama de soporte desde la rama master
$ git  checkout  -b  support/v2.3.9-company  master/v2.3.9

Git-Flow

# Creaciónn de la rama de soporte
$ git  flow  support  start  v2.3.9-company

Las instrucciones con la marca '(*)' también deben ejecutarse en Git-Flow si queremos comprometer los cambios en el repositorio centralizado (origin).