24/5/22, 09:30 Gitflow -

Sistema de Control de Versiones / Estrategia de ramificación / Gitflow

Gitflow

TABL E O F CONTENTS

1 Gitflow

a Ramas Principales
b Ramas Auxiliares
c Iniciar GitFlow
d Trabajar con Features
e Trabajando con Releases
f Trabajando con Hotfix

Vincent Driessen lo define como el conjunto de extensiones de Git que facilitan la gestión de las
ramas y flujos de Trabajo.

Ramas Principales
master: Cualquier commit que se suba en esta rama debe estar preparado para subir a Producción.
Cada que se incorpora código a la master tenemos una nueva version.

develop: Rama en la que se está el código que conformará la siguiente versión planificada de
Proyecto. Esta rama también es conocida como rama de integración.

Ramas Auxiliares
Feature:

• Se origina a partir de la rama develop.

• Se incorpora siempre a la rama develop
• Se usan para desarrollar nuevas características de la aplicación que, una vez terminadas, se
incorporan a la rama develop.
https://docs.ceiba.com.co/devops/automate/sistema-de-control-de-versiones/estrategia-ramificación/gitflow/README.html 1/4
24/5/22, 09:30 Gitflow -

• Suelen existir en repositorios locales, no en el origen (remote). Excepto cuando dos

desarrolladores están trabajando en la misma característica.

Release:

• Se usa para lanzar una nueva versión del proyecto, solo para los últimos retoques antes de
liberar la nueva versión, como cambiar el número de esta.
• Se origina a partir de la rama develop.
• Se fusiona tanto con master (para poder ser desplegadas en producción) como con develop.

Hotfix:

• Se usa para los cambios rápidos que se quieren realizar como arreglar un bug sencillo en
producción mientras que al mismo tiempo se está desarrollando una nueva funcionalidad y se
quiere desplegar este arreglo lo antes posible.
• Se crean a partir de la rama master.
• Se fusionan con master y develop.

Iniciar GitFlow
$ git flow init

https://docs.ceiba.com.co/devops/automate/sistema-de-control-de-versiones/estrategia-ramificación/gitflow/README.html 2/4
24/5/22, 09:30 Gitflow -

Esto hará una serie de preguntas sobre como se quiere nombrar a las diferentes ramas y el prefijo
de las versiones.

Si se quiere usar las opciones por defecto, se pulsa intro en todas las opciones o se puede usar la
siguiente instrucción para inicializarlo:

$ git flow init -d

Trabajar con Features

Para empezar a desarrollar una nueva funcionalidad se tiene que crear usando:

$ git flow feature start nombre_de_funcionalidad

Automáticamente te crea la rama feature/nombredefuncionalidad y se cambia a ella. Ahora, si

después de varios commits se ha terminado con esa funcionalidad:

$ git flow feature finish nombre_de_funcionalidad

Mirando la consola se ve que nos fusiona esta rama con develop, se borra esta rama y se cambia a
develop automáticamente. Si en algún momento se quiere ver que ramas de features que se tienen
actualmente, se puede hacer con:

$ git flow feature

Si se quiere retomar una de esas funcionalidades que se está realizando, por ejemplo después de
solucionar un hotfix, se puede hacer con:

$ git flow feature checkout nombre_de_funcionalidad

Trabajando con Releases

Después de haber desarrollado unas cuantas funcionalidades y haberlas commiteado, se quiere
liberar una nueva versión del proyecto. Para crear esta nueva release se tiene que usar:

$ git flow release start version_1

Se hacen los cambios necesarios para la nueva versión y se decide que está todo preparado:

$ git flow release finish version_1

Esto buscará cambios en el repositorio remoto, fusionará esta versión con las ramas master y
develop, borra la release y deja todo listo para desplegar desde la rama master.

https://docs.ceiba.com.co/devops/automate/sistema-de-control-de-versiones/estrategia-ramificación/gitflow/README.html 3/4
24/5/22, 09:30 Gitflow -

Trabajando con Hotfix

Si se está trabajando en una funcionalidad y se tiene que cambiar algo que no funciona bien en el
entorno de producción, se crea una rama de hotfix:

$ git flow hotfix start error_en_produccion

Esta rama será creada a partir de la master, ya que es lo último que se ha desplegado. Al terminar
de arreglar el problema se tiene que:

$ git flow hotfix finish error_en_produccion

Esto fusionará los cambios tanto con develop como con master, teniendo la solución al problema
listo para ser desplegado en producción.

Bibliografía

• Gitflow Workflow, Continuous Integration & Continuous Delivery

(https://medium.com/devsondevs/gitflow-workflow-continuous-integration-continuous-
delivery-7f4643abb64f)
• Automatiza tu manera de usar git con git-flow
(http://codeloveandboards.com/blog/2013/04/06/automatiza-tu-manera-de-usar-git-con-git-
flow/)
• Gitflow Workflow (https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-
workflow)
• Aprende GIT (http://aprendegit.com/que-es-git-flow/)
• git-flow cheatsheet (https://danielkummer.github.io/git-flow-cheatsheet/)

https://docs.ceiba.com.co/devops/automate/sistema-de-control-de-versiones/estrategia-ramificación/gitflow/README.html 4/4