Aprende Git de manera sencilla: Git Flow

• 1. Git Config
• 2. Iniciando o Clonando un repositorio
• 3. Comandos Básicos
• 4. El archivo .gitignore
• 5. Trabajando con ramas
• 6. Deshaciendo y modificando commits
• 7. Commits Semánticos
• 8. Tags
• 9. Comandos Avanzados
• 10. Gita Aliases
• 11. Git Flow

En este undécimo artículo sobre la guía para aprender Git de manera sencilla y desde cero, vamos a ver Git Flow.

TLDR, Git Flow son dos cosas:

• Una filosofía, que brinda un mayor control y organización en el proceso de integración continua.
• Una extensión, que contiene un conjunto de comandos que simplifican el trabajo desde consola.

La extensión de Git Flow original (de Vincent Driessen) lleva casi 10 años sin ser actualizada. Existe un fork (de Peter van der Does) que lo continúa y extiende llamado Git FLow AVH Edition.

El flujo de trabajo con Git Flow nos ayuda a organizar el repositorio y nuestro trabajo. Se establece un convenio de nombres para nuestras ramas que permite a todos los miembros del equipo saber qué es cada cosa. Además, establece unas reglas comunes a la hora de mover la información de una rama a otra.

Disponemos de un conjunto de comandos que nos ahorra tiempo. En este enlace puedes ver una comparación entre los comandos de GitFlow y lo que realmente se ejecuta por debajo.

Ramas en Git Flow

En cuanto a la política de ramas, Git Flow propone:

• Master como rama principal del proyecto. Contiene el código de producción. NUNCA trabajaremos sobre ella. De esta rama no nace ninguna excepto los hotfix.
• Develop como rama de desarrollo. NUNCA trabajaremos sobre ella. De esta rama nacen todas las ramas de feature. La rama develop se mergeará con master cuando vayamos a desplegar el proyecto a través de las releases.
• Feature serán las ramas sobre las que trabajaremos normalmente. Llevan por defecto el prefijo feature/ seguido del nombre de la rama (ej: feature/add-event-cpt). Nacen SIEMPRE desde la rama develop y mueren cuando son mergeadas.
• Hotfix son las ramas que utilizaremos para corregir errores críticos encontrados en producción. Llevan el prefijo hotfix/ seguido del nombre de la rama (ej: hotfix/fix-form-submit). Nacen SIEMPRE desde la rama master y se mergean contra master y develop, con el objetivo de poner el hotfix en producción y que también esté disponible para nuevos evolutivos en la rama de desarrollo.
• Release son las ramas que utilizaremos para crear nuevas versiones para desplegar a producción. Llevan el prefijo release/ seguido del número de versión. Es el mecanismo a través del cual mergeamos los nuevos desarrollos que tenemos en develop contra master. Es recomendable utilizar SemVer para los números de versión.
• Bugfix son ramas que se utilizan para corregir errores que aún no han llegado a producción. Llevan el prefijo bugfix/ seguido del nombre de la rama (ej: bugfix/fix-wrong-logout-link). Nacen SIEMPRE desde la rama develop.

Instalación y uso de Git Flow

Lo primero es instalar la extensión de GitFLow AVH Edition. Las instrucciones en función de tu sistema operativo las encontrarás aquí.

Después de clonar o iniciar un proyecto con Git, debemos inicializar Git Flow, y esto lo hacemos situándonos en la raíz de nuestro proyecto y utilizando el siguiente comando:

git-flow init [-d]

Git Flow nos hará una serie de preguntas desde la terminal, contestaremos por defecto (simplemente pulsando enter) todas y cada una de ellas. Si queremos evitar este paso, utilizando el flag -d se establecerán todas las configuraciones por defecto.

Which branch should be used for bringing forth production releases?
   - develop
   - master
Branch name for production releases: [master]

Which branch should be used for integration of the "next release"?
   - develop
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
Hooks and filters directory? [/Users/your-usuer/Sites/your-dirname]

Al contestar por defecto, master será nuestra rama principal, develop nuestra rama de desarrollo, las ramas de nuevas funcionalidades llevarán el prefijo feature/, las ramas para solucionar pequeños fallos que no han llegado a producción llevarán el prefijo bugfix/, las ramas para poner código en producción llevarán el prefijo release/, las ramas para solucionar fallos en producción llevarán el prefijo hotfix/ y las ramas de soporte el prefijo support/.

Ramas de feature

Cuando vayamos a desarrollar una nueva funcionalidad, o evolucionar/modificar una existente, utilizaremos ramas de feature. Para esto Git Flow nos ofrece el comando git flow feature, que a su vez nos ofrece varios subcomandos:

# Listar las ramas de feature
git flow feature

# Crear una rama de feature. El nombre es obligatorio (se añadirá automáticamente el prefijo "feature/",
# la base es opcional y nos permitiría crear la feature a partir de una rama concreta. Si no se indica por
# defecto es develop
git flow feature start <name> [<base>]

# Subir la rama al repositorio remoto
git flow feature publish <name>

# Finalizar una feature y mergearla contra develop (o la base que hayamos declarado al crearla) 
git flow feature finish <name>

# Eliminar la rama de feature
git flow feature delete <name>

Ramas de hotfix

Si se detecta un bug en producción, realizaremos un hotfix. Para esto Git Flow nos ofrece el comando git flow hotfix, que a su vez nos ofrece varios subcomandos:

# Listar las ramas de hotfix
git flow hotfix

# Crear una rama de hotfix. El nombre es obligatorio (se añadirá automáticamente el prefijo "hotfix/",
# la base es opcional y nos permitiría crear el hotfix a partir de una rama concreta. Si no se indica por
# defecto es master
git flow hotfix start <name> [<base>]

# Subir la rama al repositorio remoto
git flow hotfix publish <name>

# Finalizar un hotfix y mergearlo contra master (o la base que hayamos declarado al crearla) 
git flow hotfix finish <name>

# Eliminar la rama de hotfix
git flow hotfix delete <name>

Una rama de hotfix, una vez finalizada, se mergeará automáticamente sobre master y develop. Al finalizar una rama de hotfix, Git Flow nos pide que introduzcamos 3 mensajes:

• El primer mensaje es para el commit que se mergeará en master
• El segundo mensaje es el que Git Flow pondrá a la etiqueta o tag que va a crear para identificar esta versión
• El tercer mensaje es para el commit que se mergeará en develop

Ramas de bugfix

Si se detecta un bug en que aún no ha llegado a producción, realizaremos un bugfix. Para esto Git Flow nos ofrece el comando git flow bugfix, que a su vez nos ofrece varios subcomandos:

# Listar las ramas de bugfix
git flow bugfix

# Crear una rama de bugfix. El nombre es obligatorio (se añadirá automáticamente el prefijo "bugfix/",
# la base es opcional y nos permitiría crear el bugfix a partir de una rama concreta. Si no se indica por
# defecto es develop
git flow bugfix start <name> [<base>]

# Subir la rama al repositorio remoto
git flow bugfix publish <name>

# Finalizar un bugfix y mergearlo contra develop (o la base que hayamos declarado al crearla) 
git flow bugfix finish <name>

# Eliminar la rama de bugfix
git flow bugfix delete <name>

Los bugfix se mergearán contra develop.

Ramas de release

Las ramas de release se utilizan cuando vayamos a desplegar una nueva versión de nuestro desarrollo. Para esto Git Flow nos ofrece el comando git flow release, que a su vez nos ofrece varios subcomandos:

# Listar las ramas de release
git flow release

# Crear una rama de release. A través de hooks obligamos a que las versiones sean 'major', 'minor' o 'patch'.
# La base es opcional y nos permitiría crear el bugfix a partir de una rama concreta. Si no se indica por
# defecto es develop
git flow release start <name> [<base>]

# Subir la rama al repositorio remoto
git flow release publish <name>

# Finalizar una release y mergearlo contra develop (o la base que hayamos declarado al crearla) y master
git flow release finish <name>

# Eliminar la rama de release
git flow release delete <name>

Es recomendable que utilices SemVer para tagear las versiones.

Git Flow Hooks

La versión AVH Edition pone a nuestra disposición una serie de hooks para que podamos actuar en algún punto de la ejecución y modificar el comportamiento. Tienes algunos ejemplos sobre cómo utilizar hooks en este enlace.

Aunque puedes establecer el directorio donde almacenar tus hooks al inicializar un proyecto con Git Flow, también lo puedes indicar a posteriori. Si los hooks no son globales si no que sólo aplican a un proyecto en cuestión, puedes almacenarlos en la carpeta .git/hooks de tu repositorio.

git config --global gitflow.path.hooks [PATH_TO_DIRECTORY]
git config --global core.hooksPath [PATH_TO_DIRECTORY]

# Ejemplo
git config --global gitflow.path.hooks PATH_TO_YOUR_REPO/gitflow-hooks

Versionado Semántico automático

Hace un tiempo publiqué en GitHub un repositorio con hooks para automatizar Semantic Version en tu proyecto, y no tener que escribir el nombre de la tag manualmente cada vez que vayas a realizar una release.

Cuando vayamos a realizar una release o un hotfix, automatizamos la creación de las tags en base a si nuestra nueva versión es major, minor o patch (en hotfixes será siempre patch):

• filter-flow-release-start-version: Actuamos sobre el filtro de la versión de la release, para permitir únicamente ‘major’, ‘minor’ o ‘patch’, con el objetivo de automatizar Semantic Version. En caso contrario no dejamos continuar con el proceso.
• pre-flow-release-start: Permitimos crear la rama de release con el número de versión semántico si cumple con el patrón vX.Y.Z.
• post-flow-release-finish: Una vez se finaliza la rama de release y se crea la tag, se sube a remoto para que esté disponible esta información para el próximo despliegue.
• filter-flow-hotfix-start-version: Actuamos sobre el filtro de la versión de la hotfix, para permitir únicamente versiones ‘patch’, con el objetivo de automatizar Semantic Version. En caso contrario no dejamos continuar con el proceso.
• pre-flow-hotfix-start: Permitimos crear la rama de hotfix con el número de versión semántico si cumple con el patrón vX.Y.Z.
• post-flow-hotfix-finish: Una vez se finaliza la rama de hotfix y se crea la tag, se sube a remoto para que esté disponible esta información para el próximo despliegue.

• « Aprende Git de manera sencilla:…
• Cómo trabajar con los crons… »