Git Flow

Flujo de Trabajo automatizado para Git

Sitio Web: https://github.com/nvie/gitflow

Definición
Es una herramienta que permite automatizar el flujo de trabajo con ramas de git, usando para
ello un conjunto de comandos (extensiones) que se agregan a nuestro repositorio git.
Git Flow propone un modelo de trabajo basado en las siguientes ramas:
● master
● develop
● feature
● release
● hotfix
● support
Dicho modelo de trabajo se encuentra basado en el modelo de ramas propuesto por Vincent
Driessen's en http://nvie.com/posts/a-successful-git-branching-model/

Esquema de Trabajo
A continuación se describe brevemente el uso y finalidad de cada rama:
● master: Es la rama base del proyecto, se considera que todo el código en master debe
estar listo para salir a producción. Esta rama se alimenta básicamente de todo el trabajo
realizado en la rama develop a través de los release. Debería ser modificada
únicamente por el Integrador del proyecto a traves de ramas release y hotfix.
● develop: Es la rama base de trabajo para los desarrolladores. Originalmente se crea
automáticamente desde master y todo el trabajo de los desarrolladores que se realiza
en ramas de tipo feature se integra en develop y de develop puede pasar a master
cuando se decida creando un release, todo esto de forma automatizada como se
explicará más adelante con los comandos de git flow.
● feature: Es la rama de trabajo de un desarrollador (ó varios en conjunto) que trabaje(n)
para desarrollar una funcionalidad (feature). Se crean a partir de la rama develop y al
finalizar el trabajo se cierra el feature y se integra en develop. El feature es eliminado,
aunque gitflow tiene un parametro para evitarlo.
● release: es una rama de trabajo que se crea como base para realizar una integración
de develop a master, esto lo hace git flow tomando un snapshop de develop en el
momento que se crea el release, tras lo cual se hacen los ajustes/cambios que se
consideren pertinentes a través de commits normales, tras lo cual se cierra el release
por lo cual gitflow integra el contenido de esta rama en master y develop, y crea un tag
que identifica la nueva versión integrada en master. Esta rama puede usarse para QA
(Control de Calidad).
● hotfix: Esta rama se crea basada en master como consecuencia de “correcciones en
caliente” necesarias para fallas detectadas en producción. Al cerrarse un hotfix se
integra en master y develop.

Página 1
Elaborado por: William Yánez (wyanez@gmail.com)
Versión 1.0 01/04/2014 - Revisado al: 04/03/2020
 ● support: este es un tipo de rama opcional soportado actualmente en modo
experimental por gitflow para cambios puntuales que deban hacerse a versiones
liberadas para satisfacer la demanda específica de ciertos clientes/usuarios del sistema.
Se crean a partir de un commit específico de master.

Comandos (Flujo de Trabajo).

● Inicialización de Git Flow en un repositorio existente:
○ git flow init
○ Este comando crea automáticamente la rama develop a partir de
master y la establece como rama activa. Debe hacerlo cada
desarrollador en su repositorio la primera vez.

● Sintaxis básica de los comandos de git flow:

○ git flow subcomando accion nombre_rama
○ Donde subcomando puede ser: feature, release, hotfix,
support.
○ Donde acción puede ser: list, start, finish, publish.

● Creación de un Feature:
○ git flow feature start nombre_feature
○ Este comando crea automáticamente la rama nombre_feature a partir
de develop y la establece como rama activa, luego el desarrollador
puede trabajar en ella normalmente, haciendo los respectivos
commits hasta que finalice el feature. Básicamente es un:
git checkout -b nombre_feature develop

● Finalización de un Feature:
○ git flow feature finish nombre_feature
○ Este comando finaliza automáticamente la rama nombre_feature, la
integra (merge) en develop y la elimina (se puede evitar con el
parámetro -k).
○ Básicamente se traduce en los siguientes comandos de Git:
$ git checkout develop
$ git merge --no-ff nombre_feature
$ git branch -d nombre_feature
Nota: la opción --no-ff en el merge la cual crea un commit vacio por cada merge que se realiza,
pero permite saber de que branch vienen los commits

● Publicación de un Feature en el repositorio remoto (bitbucket para nosotros):

○ git flow feature publish nombre_feature
○ Este comando publica automáticamente la rama nombre_feature en el
repositorio remoto (origin) tras lo cual luego puede ser
actualizada periódicamente con el comando git push origin. Esto se
hace con el fin de compartir la rama con los otros desarrolladores
del proyecto para fines de revisión, corrección, pair-
programming,etc...

Página 2
Elaborado por: William Yánez (wyanez@gmail.com)
Versión 1.0 01/04/2014 - Revisado al: 04/03/2020
 ● Creación de un Release:
○ git flow release start nro_version
○ Este comando crea automáticamente la rama nro_version a partir de
develop y la establece como rama activa, luego el integrador (y
desarrolladores) puede trabajar en ella normalmente para hacer los
ajustes/cambios que considere necesario, haciendo los respectivos
commits hasta que finalice la rama. Básicamente es un:
git checkout -b nro_version develop

● Finalización de un Release:
○ git flow release finish nro_version
○ Este comando finaliza automáticamente la rama nro_version, la
integra (merge) en master y develop y la elimina. Crea un tag con
el nro de versión.
○ Básicamente se traduce en los siguientes comandos de Git:
$ git checkout master
$ git merge --no-ff nro_version
$ git tag nro_version
$ git checkout develop
$ git merge --no-ff nro_version
$ git branch -d nro_version

● Publicación de un release en el repositorio remoto (bitbucket para nosotros):

○ git flow release publish nro_version

● Manejo de ramas HotFix (para correcciones en master):

○ git flow hotfix start nro_nueva_versión
○ git flow hotfix finish nro_nueva_versión

Instalación
(Windows, Mac y Linux): https://github.com/nvie/gitflow/wiki/Installation
● Linux Ubuntu/Debian: sudo aptitude install git-flow
● Windows (ToDo Revisar, fue probado y funciona bajo WinXP y Win7)
1. Ubicarse en C:\ con el Explorador de Win y Abrir una consola de Git (Boton Derecho ->Git Bash)
2. En la Consola (Git Bash) ejecutar:
1. $ git clone --recursive git://github.com/nvie/gitflow.git
3. Descarga el archivo para_instalar_gitflow_win.zip desde aqui http://db.tt/fTgPNdXi
4. Descomprimelo y copia los 2 archivos (getopt.exe y libintl3.dll) en C:\Archivos de programa\Git\
bin
5. Abre una Consola de Windows Normal (cmd) Ejecuta:
1. C:\gitflow> contrib\msysgit-install
6. y listo... para verificar la instalación abre una consola de Git (Git Bash) y ejecuta: git-flow

Página 3
Elaborado por: William Yánez (wyanez@gmail.com)
Versión 1.0 01/04/2014 - Revisado al: 04/03/2020
Como adoptar el esquema de Trabajo con Git Flow
1. Debemos depurar el repositorio actual (cerrar las ramas abiertas, integrarlas en master)
hasta dejar solamente la rama master.
2. Inicializamos Git Flow en nuestro repositorio (git flow init). Esto creará la rama develop
como un snapshot de master.
3. Actualizamos el repositorio remoto (origin).
4. Luego cada desarrollador debe hacer lo siguiente (solo la primera vez):
a. clonar el proyecto nuevamente (para tener un espacio de trabajo limpio).
b. en la consola de git ejecutar el comando:
git checkout -b develop -t origin/develop
para crear una rama local develop que apunte (track) al develop en origin.
c. Hacer git flow init en la carpeta del proyecto

5. Flujo de trabajo de cada Desarrollador para los features:

a. Crear un feature con un nombre descriptivo como identificador ( git flow feature
start feature/nombre-feature)
b. Realizar las tareas de programación requeridas y hacer los commits que se
necesiten normalmente.
c. Publicar la rama en remoto (git flow feature publish feature/nombre-feature ) y
actualizarla al final de cada día con git push origin ó cuando se considere
necesario para mantener actualizado al resto del equipo de sus avances.
d. Al terminar de desarrollar el feature, finalizar el mismo ( git flow feature finish
feature/nombre-feature) lo cual integrará esta rama en develop.
e. Actualizar develop en remoto (git push origin develop).

6. Flujo de trabajo del integrador para los features finalizados:

a. Actualizar develop en su proyecto local (git pull)
b. Revisar los commits realizados en el feature finalizado y verificar si se encuentra
implementada debidamente (correr los tests de integración, unitarios, si existen).
c. De ser así, y si lo cree conveniente, puede crear un release (git flow release start
v0.1) para uso del equipo de QA (Esta rama release se crea como un snapshop
de develop) y publicar el release (git flow release publish v0.1)
d. En caso de recibir indicaciones de correcciones, el integrador y desarrolladores
pueden trabajar sobre esta rama, hacer los commits requeridos y notificar al
equipo de QA para nueva revisión.
e. Al finalizar la revisión y estar de acuerdo el equipo de QA se cierra el release (git
flow release finish v0.1) lo cual lleva a integrar (merge) los cambios realizados
en esta rama en master y los envía de vuelta a develop para mantener
sincronizado todo.

Página 4
Elaborado por: William Yánez (wyanez@gmail.com)
Versión 1.0 01/04/2014 - Revisado al: 04/03/2020
 7. Flujo de trabajo del equipo QA para los features finalizados:
a. git pull origin --all
b. git flow release track v0.1 (para crear una rama local release/v0.1 que apunte
a origin/release/v0.1)
c. Realizar las revision y hacer las indicaciones respectivas al integrador.
d. Al estar de acuerdo con lo implementado en el release se notifica al integrador
para cerrar este release e integrarlo en producción (master).

Página 5
Elaborado por: William Yánez (wyanez@gmail.com)
Versión 1.0 01/04/2014 - Revisado al: 04/03/2020