Flujo de trabajo de Gitflow

El flujo de trabajo de Gitflow es un diseño de flujo de trabajo de Git que fue publicado por primera vez y popularizado por Vincent Driessen en nvie. El flujo de trabajo de Gitflow define un modelo estricto de ramificación diseñado alrededor de la publicación del proyecto. Proporciona un marco sólido para gestionar proyectos más grandes.  

Gitflow es ideal para los proyectos que tienen un ciclo de publicación programado. Este flujo de trabajo no añade ningún concepto ni comando nuevos más allá de lo que se necesita para el flujo de trabajo de rama de función. En su lugar, asigna funciones muy específicas a las diferentes ramas y define cómo y cuándo deben interactuar. Además de las ramas de función, utiliza ramas individuales para preparar, mantener y registrar publicaciones. Por supuesto, también te aprovechas de todos los beneficios del flujo de trabajo de rama de función: solicitudes de incorporación de cambios, experimentos aislados y una colaboración más eficaz.

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. En los sistemas OSX, puedes ejecutar brew install git-flow. En Windows, tendrás que descargar e instalar git-flow. Después de instalar git-flow, puedes utilizarlo en tu proyecto ejecutando git flow init. Git-flow es un envoltorio de Git. El comando git flow init es una extensión del comando predeterminado git init y no cambia nada de tu repositorio aparte de crear ramas para ti.

Funcionamiento

Ramas de desarrollo y maestras

En vez de una única rama maestra, este flujo de trabajo utiliza dos ramas para registrar el historial del proyecto. La rama maestra almacena el historial de publicación oficial y la rama de desarrollo sirve como rama de integración para funciones. Asimismo, conviene etiquetar todas las confirmaciones de la rama maestra con un número de versión.

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

git branch develop
git push -u origin develop

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

Al utilizar la biblioteca de extensiones de git-flow, ejecutar git flow init en un repositorio existente creará la rama de desarrollo:

$ git flow init
Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

$ git branch
* develop
 master

Ramas de función

Cada nueva función debe estar en su propia rama, que se puede enviar al repositorio central para copia de seguridad/colaboración. Sin embargo, en vez de ramificarse de la maestra, las ramas de función utilizan la de desarrollo como rama primaria. Cuando una función está completa, se vuelve a fusionar en la de desarrollo. Las funciones nunca deben interactuar directamente con la maestra.

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

Las ramas de función normalmente se crean a partir de la última rama de desarrollo.

Creación de una rama de función

Sin las extensiones de git-flow:

git checkout develop
git checkout -b feature_branch

Cuando se utiliza la extensión de git-flow:

git flow feature start feature_branch

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

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.

Sin las extensiones de git-flow:

git checkout develop
git merge feature_branch

Con las extensiones de git-flow:

git flow feature finish feature_branch

Ramas de publicación

Una vez que el desarrollo ha adquirido suficientes funciones para una publicación (o se está acercando una fecha de publicación predeterminada), bifurcas una rama de versión a partir de una de desarrollo. Al crear esta rama, se inicia el siguiente ciclo de publicación, por lo que no pueden añadirse nuevas funciones tras este punto; solo las soluciones de errores, la generación de documentación y otras tareas orientadas a la publicación deben ir en esta rama. Una vez que esté lista para el lanzamiento, la rama de publicación se fusiona en la maestra y se etiqueta con un número de versión. Además, debería volver a fusionarse en la de desarrollo, que podría haber progresado desde que se inició la publicación.

Utilizar una rama específica para preparar publicaciones hace posible que un equipo perfeccione la publicación actual mientras otro equipo sigue trabajando en las funciones para la siguiente publicación. Asimismo, crea fases de desarrollo bien definidas (por ejemplo, es fácil decir: "Esta semana nos estamos preparando para la versión 4.0" y verlo escrito en la estructura del repositorio).

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

Sin las extensiones de git-flow:

git checkout develop
git checkout -b release/0.1.0

Cuando se utilizan las extensiones de git-flow:

$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'

Una vez que la publicación esté lista para su lanzamiento, se fusionará en la maestra y la de desarrollo; a continuación, se eliminará la rama de publicación. Es importante volver a fusionarla en la de desarrollo porque podrían haberse añadido actualizaciones críticas a la rama de publicación y las nuevas funciones tienen que poder acceder a ellas. Si tu organización enfatiza la revisión de código, sería el lugar ideal para una solicitud de incorporación de cambios.

Para finalizar una rama de publicación, utiliza los siguientes métodos:

Sin las extensiones de git-flow:

git checkout master
git merge release/0.1.0

O con la extensión de git-flow:

git flow release finish '0.1.0'

Ramas de corrección

Las ramas de mantenimiento o "corrección" (hotfix) se utilizan para reparar rápidamente las publicaciones de producción. Las ramas de corrección son muy similares a las ramas de publicación y a las de función, salvo porque se basan en la maestra en vez de la de desarrollo. Es la única rama que debería bifurcarse directamente a partir de la maestra. Una vez que la solución esté completa, debería fusionarse en la maestra y la de desarrollo (o la rama de publicación actual), y la maestra debería etiquetarse con un número de versión actualizado.

Tener una línea de desarrollo específica para la solución de errores permite que tu equipo aborde las incidencias sin interrumpir el resto del flujo de trabajo ni esperar al siguiente ciclo de publicación. Puedes considerar las ramas de mantenimiento como ramas de publicación ad hoc que trabajan directamente con la maestra. Una rama de corrección puede crearse utilizando los siguientes métodos:

Sin las extensiones de git-flow:

git checkout master
git checkout -b hotfix_branch

Cuando se utilizan las extensiones de git-flow: 

$ git flow hotfix start hotfix_branch

Al igual que al finalizar una rama de publicación, una rama de corrección se fusiona tanto en la maestra como en la de desarrollo.

git checkout master
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch

$ git flow hotfix finish hotfix_branch

Ejemplo

A continuación, se incluye un ejemplo completo que demuestra un flujo de ramas de función. Vamos a asumir que tenemos una configuración del repositorio con una rama maestra.

git checkout master
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout master
git merge develop
git branch -d feature_branch

Además del flujo de función y publicación, un ejemplo de corrección sería de la siguiente manera:

git checkout master
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout master
git merge hotfix_branch

Resumen

En este artículo, hemos explicado el flujo de trabajo de Gitflow. Gitflow es uno de los muchos estilos de flujos de trabajo de Git que podéis utilizar tu equipo y tú.

Algunos puntos clave que debes saber sobre Gitflow son los siguientes:

• Este flujo de trabajo es ideal para los flujos de trabajo de software basados en publicaciones.
• Gitflow ofrece un canal específico para las correcciones de producción.
   

El flujo general de Gitflow es el siguiente:

1. Se crea una rama de desarrollo a partir de la maestra.
2. Una rama de publicación se crea a partir de la de desarrollo.
3. Las ramas de función se crean a partir de la de desarrollo.
4. Cuando una función está completa, se fusiona en la rama de desarrollo. 
5. Cuando la rama de publicación está lista, se fusiona en la de desarrollo y la maestra.
6. Si se detecta una incidencia en la maestra, se crea una rama de corrección a partir de la maestra.
7. Una vez que la corrección está completa, se fusiona tanto con la de desarrollo como con la maestra.

A continuación, obtén información sobre el Flujo de trabajo de bifurcación o visita nuestra página de comparación de flujos de trabajo.