Gitflow Workflow es un flujo de trabajo Git que ayuda al desarrollo continuo de software y a la implementación de prácticas DevOps. Fue publicado y popularizado por primera vez por Vincent Driessen en nvie. El flujo de trabajo Gitflow define un estricto modelo de ramificación diseñado en torno a la liberación del proyecto. Esto proporciona un marco robusto para la gestión de proyectos más grandes.

Gitflow es ideal para proyectos que tienen un ciclo de lanzamiento programado y para la mejor práctica DevOps de entrega continua. Este flujo de trabajo no añade ningún concepto o comando nuevo más allá de lo que se requiere para el flujo de trabajo de la rama de características. En cambio, asigna roles muy específicos a las diferentes ramas y define cómo y cuándo deben interactuar. Además de las ramas feature, utiliza ramas individuales para la preparación, el mantenimiento y el registro de versiones. Por supuesto, también consigues aprovechar todos los beneficios del flujo de trabajo de la rama de características: pull requests, experimentos aislados y una colaboración más eficiente.

Comenzando

Gitflow es realmente una idea abstracta de un flujo de trabajo Git. Esto significa que dicta qué tipo de ramas configurar y cómo fusionarlas. Más adelante tocaremos los propósitos de las ramas. El conjunto de herramientas git-flow es una herramienta de línea de comandos real que tiene un proceso de instalación. El proceso de instalación de git-flow es sencillo. Los paquetes para git-flow están disponibles en varios sistemas operativos. En 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 usarlo en tu proyecto ejecutando git flow init. Git-flow es una envoltura alrededor de Git. El comando git flow init es una extensión del comando por defecto git init y no cambia nada en tu repositorio más allá de crear ramas por ti.

Cómo funciona

Rama de desarrollo y rama maestra

En lugar de una única master rama, este flujo de trabajo utiliza dos ramas para registrar la historia del proyecto. La rama master almacena el historial de la versión oficial, y la rama develop sirve como rama de integración para las características. También es conveniente etiquetar todos los commits de la rama master con un número de versión.

El primer paso es complementar el master por defecto con una rama develop. Una forma sencilla de hacerlo es que un desarrollador cree una rama vacía develop localmente y la empuje al servidor:

git branch develop
git push -u origin develop

Esta rama contendrá el historial completo del proyecto, mientras que master contendrá una versión abreviada. Los demás desarrolladores deben clonar ahora el repositorio central y crear una rama de seguimiento para develop.

Cuando se utilice la biblioteca de extensión git-flow, al ejecutar git flow init en un repo existente se creará la rama develop:

$ 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:
Branch name for "next release" development:
How to name your supporting branch prefixes?
Feature branches?
Release branches?
Hotfix branches?
Support branches?
Version tag prefix?
$ git branch
* develop
master

Rama de características

Cada nueva característica debe residir en su propia rama, que puede ser empujada al repositorio central para la copia de seguridad/colaboración. Pero, en lugar de derivar de master, las ramas feature utilizan develop como su rama madre. Cuando una característica está completa, se fusiona de nuevo en el desarrollo. Las características nunca deben interactuar directamente con master.

Nota que las ramas feature combinadas con la rama develop es, a todos los efectos, el flujo de trabajo de la rama de características. Pero, el flujo de trabajo de Gitflow no se detiene ahí.

Feature las ramas se crean generalmente fuera de la última develop rama.

Creando una rama de características

Sin las extensiones git-flow:

git checkout develop
git checkout -b feature_branch

Cuando se usa la extensión git-flow:

git flow feature start feature_branch

Continúa tu trabajo y usa Git como lo harías normalmente.

Acabando una rama de la característica

Cuando hayas terminado con el trabajo de desarrollo de la característica, el siguiente paso es fusionar el feature_branch en develop.

Sin las extensiones git-flow:

git checkout develop
git merge feature_branch

Usando las extensiones git-flow:

git flow feature finish feature_branch

Liberar ramas

Una vez que develop ha adquirido suficientes características para una liberación (o se acerca una fecha de liberación predeterminada), se bifurca una rama release de develop. La creación de esta rama inicia el siguiente ciclo de lanzamiento, por lo que no se pueden añadir nuevas características después de este punto: sólo las correcciones de errores, la generación de documentación y otras tareas orientadas al lanzamiento deben ir en esta rama. Una vez que esté lista para el lanzamiento, la rama release se fusiona con master y se etiqueta con un número de versión. Además, debe fusionarse de nuevo en develop, que puede haber progresado desde que se inició el lanzamiento.

Utilizar una rama dedicada para preparar los lanzamientos hace posible que un equipo pula la versión actual mientras otro equipo sigue trabajando en las características de la siguiente versión. También crea fases de desarrollo bien definidas (por ejemplo, es fácil decir: «Esta semana estamos preparando la versión 4.0», y verlo realmente en la estructura del repositorio).

Hacer ramas release es otra operación de ramificación directa. Al igual que las ramas feature, las ramas release se basan en la rama develop. Se puede crear una nueva rama release 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 versión esté lista para ser enviada, se fusionará en master y develop, entonces se eliminará la rama release. Es importante volver a fusionar en develop porque es posible que se hayan añadido actualizaciones críticas a la rama release y es necesario que sean accesibles a las nuevas características. Si tu organización hace hincapié en la revisión del código, este sería un lugar ideal para un pull request.

Para terminar una release rama, utiliza los siguientes métodos:

Sin las extensiones git-flow:

git checkout master 
git merge release/0.1.0

O con la extensión git-flow:

git flow release finish '0.1.0'

Bramas de revisión

Las ramas de mantenimiento o "hotfix” se utilizan para parchear rápidamente las versiones de producción. Las ramas Hotfix son muy parecidas a las ramas release y a las ramas feature excepto que se basan en master en lugar de develop. Esta es la única rama que debe bifurcarse directamente de master. Tan pronto como se complete la corrección, debería fusionarse tanto en master como en develop (o en la rama actual release), y master debería etiquetarse con un número de versión actualizado.

Tener una línea de desarrollo dedicada a la corrección de errores permite a tu equipo abordar los problemas sin interrumpir el resto del flujo de trabajo o esperar al siguiente ciclo de lanzamiento. Puedes pensar en las ramas de mantenimiento como ramas ad hoc release que trabajan directamente con master. Una hotfix rama se puede crear 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

Similar a terminar una release rama, una rama hotfix se fusiona tanto en master como en develop.

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

Un ejemplo completo que demuestra el flujo de una rama de características es el siguiente. Suponiendo que tenemos una configuración de repo con una master rama.

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 feature y release flujo, un hotfix ejemplo es el siguiente:

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

Aquí hemos hablado del flujo de trabajo Gitflow. Gitflow es uno de los muchos estilos de flujos de trabajo de Git que usted y su equipo pueden utilizar.

Algunos puntos clave a saber sobre Gitflow son:

  • El flujo de trabajo es grande para un flujo de trabajo de software basado en la liberación.
  • Gitflow ofrece un canal dedicado para hotfixes a la producción.
  • El flujo general de Gitflow es:

  1. Una develop rama se crea a partir de master
  2. Una release rama se crea a partir de develop
  3. Feature se crean ramas a partir de develop
  4. Cuando un feature está completo se fusiona con la rama develop
  5. Cuando el release rama esté terminada se fusiona en develop y master
  6. Si se detecta una incidencia en master una hotfix se crea una rama a partir de master
  7. Una vez que la hotfix está completa se fusiona tanto con develop como con master
  8. Siguiente, conozca el flujo de trabajo de bifurcación o visite nuestra página de comparación de flujos de trabajo.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *