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:
- Una
develop
rama se crea a partir demaster
- Una
release
rama se crea a partir dedevelop
-
Feature
se crean ramas a partir dedevelop
- Cuando un
feature
está completo se fusiona con la ramadevelop
- Cuando el
release
rama esté terminada se fusiona endevelop
ymaster
- Si se detecta una incidencia en
master
unahotfix
se crea una rama a partir demaster
- Una vez que la
hotfix
está completa se fusiona tanto condevelop
como conmaster
Siguiente, conozca el flujo de trabajo de bifurcación o visite nuestra página de comparación de flujos de trabajo.