Gitflow Web

Entendiendo Git Flow :: SysVar about:reader?url=https://sysvar.net/es/entendiendo-git...
sysvar.net
Entendiendo Git Flow :: SysVar

Jose Ignacio Galarza (@igalarzab)
Una de las caractersticas que ms me gustan de Git es

que es una autntica navaja suiza en cuanto a que
permite seguir el flujo de trabajo que ms nos convenga
en nuestro proyecto.
La potencia que tiene la gestin de ramas, la forma en la

que est diseado y el hecho de que sea distribuido nos
permite adoptar multitud de flujos; desde el ms simple
en el que imitamos un repositorio centralizado como
subversion hasta otros ms complicados en los que se
crean multitud de ramas y servidores que nos ayudan a
organizar y jerarquizar mejor todo.
Hoy vamos a hablar de uno de estos ltimos, un modelo

que ha cobrado muchsima fama ltimamente y que a
pesar de poder ser algo lioso al principio, veremos que
nos puede ayudar muchsimo en el da a da.
1 of 16 27/03/17 22:39
Este artculo est dividido en dos partes (enlace a la

segunda parte), siendo esta primera la encargada de
explicar el flujo de trabajo a seguir y la segunda la
encargada de explicar como usar git-flow, una
herramienta creada para facilitar el uso de este modelo
(se instala como un plugin de git).
Entendiendo este artculo
Para leer este artculo hay que tener una base (tampoco
demasiado amplia) sobre gestores de versiones
distribuidos (Git, Bazar, Mercurial, ...) y sobre
terminologa Git.
Como repaso rpido recordemos lo siguiente:
El trmino HEAD referencia al ltimo commit existente

en la rama en la que estemos.
Llamaremos origin al servidor central donde estar

alojado nuestro proyecto.
Usaremos la nomenclatura estndar al nombrar ramas:

servidor/nombre_rama.
2 of 16 27/03/17 22:39
Y poco ms. Sabido esto podemos empezar... :)
El modelo de ramas acertado de Git
O como se llama en ingls A successful Git branching

model (lo que es poco acertado es la traduccin que he
hecho).
Creado por Vincent Driessen, es un modelo de flujo de

trabajo para Git que da muchsima importancia a las
ramas y que de hecho las crea de varios tipos, de forma
temtica, tal que cada tipo de rama es creada con un
objetivo en concreto.
A continuacin vamos a ir explicando cada uno de estos

tipos, con el uso y el objetivo que tienen en este flujo de
trabajo.
La rama master
La rama master es la nica rama existente que nos

proporciona Git al crear un repositorio nuevo.
Esta rama (sincronizada en todo momento con
3 of 16 27/03/17 22:39
origin/master) tiene como objetivo ser el contenido

del servidor de produccin. Es decir, el HEAD de esta
rama ha de apuntar en todo momento a la ltima versin
de nuestro proyecto.
Como podemos ver, cada commit (ilustrado por las

pelotitas) es una nueva versin del proyecto, que a su
vez est referenciada mediante un tag (representada por
la nube).
No se va a desarrollar desde esta rama en ningn

momento.
La rama develop
Esta rama funciona paralelamente a la master. Si la

anterior contena las versiones desplegadas en
produccin, esta (que tambin estar sincronizada con
origin/develop) contendr el ltimo estado de
nuestro proyecto. Es decir, esta rama contiene todo el
4 of 16 27/03/17 22:39
desarrollo del proyecto hasta el ltimo commit realizado.
Cuando esta rama adquiera estabilidad y los

desarrolladores quieran lanzar una nueva versin,
bastar con hacer un merge a la rama master (no de
forma directa, ya veremos como hacerlo) y asignarle un
nmero de versin mediante un tag.
Esto ser lo que cree una nueva versin de nuestro

proyecto. Recordemos que queremos ser bastante
estrictos en cuanto a que el master solo alojar
commits que supongan nuevas versiones. Nada ms.
Para ver el estado del desarrollo usaremos la rama
develop.
Las ramas de features
Que varias personas trabajen sobre la misma rama es

bastante catico ya que se aumenta el nmero de
conflictos que se dan. A pesar de que los repositorios
distribuidos faciliten esta tarea al guardar los commits
solo localmente, tiene mucho ms sentido usar la
5 of 16 27/03/17 22:39
potencia de las ramas de Git.
Cada vez que necesitemos programar una nueva

caracterstica en nuestro proyecto crearemos una nueva
rama para la tarea. De hecho, lo utpico sera que todo
el desarrollo se realizase en este tipo de ramas.
Estas ramas pueden tener cualquier nombre que no

empiece por release-, hostfix-, ni master o
develop. El nombre deber reflejar el propsito de la
rama (ej. form_registro_usuarios, i18n,
bug_1134, ...).
Ya que develop contiene la ltima foto de nuestro

proyecto, crearemos la nueva rama a partir de aqu.
$ git checkout -b bug_1134 develop
Una vez finalizada la tarea, solo tendremos que integrar

la rama creada dentro de develop. Para esto
usaremos un merge normal y corriente con un
parmetro extra, --no-ff.
Este flag obliga a Git ha generar un commit para el
6 of 16 27/03/17 22:39
merge. Con esto se evita que Git haga un

fast-forward si es posible (es uno de los mtodos
para realizar merges, en los que se pierde la historia de
la rama).
De esta manera, en todo momento en la historia del

repositorio se tendr constancia de que hubo una rama
donde se desarroll cierta funcionalidad, que commits
contena, y cuando se integr en el trunk.
Una vez integrada la rama en develop, podremos

eliminarla y actualizar origin.
$ git checkout develop

$ git merge --no-ff bug_1134
$ git branch -d bug_1134
$ git push origin develop
Por ltimo, estas ramas no tienen por qu estar

necesariamente subidas a origin, aunque si se quiere
compartir ese desarrollo entre varios programadores,
7 of 16 27/03/17 22:39
puede hacerse sin problemas.
Las ramas de lanzamiento
Como hemos dicho antes, el desarrollo del proyecto ha

de realizarse en la rama develop, para posteriormente
lanzar una nueva versin desde la rama master.
Esto no se har directamente con un merge desde la

rama develop a master, si no que se usarn las
ramas de lanzamiento para este fin.
Este tipo de ramas sirve para poder liberar cuanto antes

la rama develop para continuar el desarrollo, y alojar
todos aquellos commits que son de preparacin para el
lanzamiento de la versin: cambiar el nmero de la
versin en los ficheros, compilar la documentacin
necesaria, empaquetar libreras, etc.
Es decir, todo aquello que no tiene que ver directamente

con el desarrollo, si no con el lanzamiento de la
siguiente versin del proyecto.
La creacin de esta rama ser anloga a las de otros
8 of 16 27/03/17 22:39
tipos, teniendo en cuenta que tendr que prefijarse con

el nombre release-, seguido del nmero de versin
que tendr.
$ git checkout -b release-1.2 develop
Una vez terminada la preparacin de la siguiese, habr

que realizar un merge del HEAD de la rama release con
el master. De esta forma se crear una nueva versin.
Por ltimo, se crear un tag en el commit del master

para marcar la versin.
Como se puede ver en el grfico, los cambios no slo se

integrarn en el master, si no que tambin lo harn en
la rama develop, de esta manera no perderemos los
cambios realizados en la rama release, y se
9 of 16 27/03/17 22:39
integrarn en el desarrollo. Por ltimo, y dado que ya no

hace falta, podemos borrar la rama creada.
As pues, las instrucciones para finalizar una rama de

lanzamiento son las siguientes:
$ git checkout master

$ git merge --no-ff release-1.2
$ git tag -a 1.2
$ git merge --no-ff release-1.2
$ git branch -d release-1.2
Como detalle adicional mencionar que en las ramas de

lanzamiento no se puede aadir funcionalidad al
producto. Es una rama cuyo objetivo es nicamente el
realizar el trabajo necesario para lanzar una nueva
release.
Si en este proceso se detectase un bug nuevo, se

corregira en la rama de lanzamiento. Al finalizarla, como
el trabajo se integrar en la rama develop, el commit
que arregl dicho fallo se incluir igualmente.
10 of 16 27/03/17 22:39
Las ramas de bugs urgentes
Y por ltimo tenemos las ramas de bugs urgentes. Estas

ramas son muy parecidas en funcionamiento a las
ramas de lanzamiento. Su propsito es arreglar algn
fallo en el desarrollo que necesita de una nueva release
del proyecto inmediatamente.
Esta rama se crear a partir de master ya que

nicamente queremos resolver el fallo (sin incluir nada
del nuevo desarrollo realizado en la rama develop). Su
nombre deber prefijarse mediante hotfix- y una vez
creada la rama simplemente se corregir el fallo desde
la misma.
$ git checkout -b hotfix-1.1.2 master
Una vez corregido el fallo tendremos que integrar el

arreglo en el master. Para ello, y como siempre, se har
un merge y se crear un tag para indicar que se ha
creado una nueva versin del proyecto.
Tambin se tendr que integrar la correccin del bug en

la rama develop, ya que no queremos perder el fix en
11 of 16 27/03/17 22:39
el desarrollo de futuras versiones.
Los comandos necesarios para llevar a cabo la

finalizacin de la rama hotfix son los siguientes:
$ git checkout master

$ git merge --no-ff hotfix-1.1.2
$ git tag -a 1.1.2
$ git merge --no-ff hotfix-1.1.2
Hay que tener en cuenta una pequea excepcin, el

caso en el que exista una rama de lanzamiento cuando
creamos la rama hotfix.
En este caso, se har todo exactamente igual con una

salvedad. Y es que a la hora de integrar los commits de
12 of 16 27/03/17 22:39
la rama hotfix, por un lado lo haremos al master y

por el otro, en vez de a la rama develop, lo haremos a
la rama de lanzamiento.
De esta manera, el bug se ver corregido en la nueva

versin que est a punto de lanzarse, y, cuando esta se
integre en develop (recordad que las ramas de
lanzamiento se integran en el master y en develop al
finalizarse), se ver corregido en el resto del desarrollo.
Las ramas de soporte
Estas ramas sirven para ofrecer soporte a largo alcance

de una versin del proyecto. Podemos tener varias
versiones en produccin, las 1.x y las 2.x.
En caso de que no queramos matar el desarrollo de la

1.x porque an nos es necesario, podemos usar este
tipo de ramas para facilitar el mantenimiento de ambos
desarrollos en paralelo.
En cualquier caso, el soporte de estas ramas est an

en proceso muy experimental, por lo que a fecha de este
artculo es mejor no usarlas.
13 of 16 27/03/17 22:39
Resumiendo...
Como podis ver aunque este flujo de trabajo es algo

rebuscado, se adapta muy bien al trabajo real que se
hace en muchos desarrollos.
En el prximo artculo veremos git-flow, una herramienta

creada para facilitar el seguir este flujo de trabajo. Como
habris visto, las formas de crear y finalizar las ramas
son siempre prcticamente iguales, y, aparte, en el caso
de la integracin de los cambios, hay que pasar el flag
no-ff siempre al comando. git-flow naci para
evitar errores en estos aspectos y para facilitar el da a
da al seguir este flujo (ejecutar un solo comando para
finalizar una rama, en vez de cinco por ejemplo).
Y por ltimo, y como chuleta para tener siempre cerca,

un resumen de los tipos de ramas:
Master
Cada commit indica una nueva versin del proyecto.
Se crea a partir de: -
Se integra en: -
14 of 16 27/03/17 22:39
Develop
Contiene el desarrollo del proyecto
Se crea a partir de: -
Se integra en: -
Feature branch
Cada rama contiene el desarrollo de una
funcionalidad.
Se crea a partir de: develop
Se integra en: develop
Release branch (release-XXX)

Se realiza el trabajo necesario para lanzar una nueva
versin.
Se crea a partir de: develop
Se integra en: develop y master
Hotfix branch (hotfix-XXX)

Se corrige un fallo urgente.
15 of 16 27/03/17 22:39
Se crea a partir de: master
Se integra en: develop y master
Podis ver un resumen general de todo lo contado aqu

en un pdf creado por el autor de este modelo. En el
apartado de referencias (a continuacin de esto), tenis
igualmente el enlace al post original, donde se explica
todo muchsimo mejor que aqu, pero en un castizo
ingls ;)
16 of 16 27/03/17 22:39

Gitflow Web

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Gitflow Web

Cargado por

Copyright:

Formatos disponibles

Entendiendo Git Flow :: SysVar about:reader?url=https://sysvar.net/es/entendiendo-git...

Entendiendo Git Flow :: SysVar

Una de las caractersticas que ms me gustan de Git es

La potencia que tiene la gestin de ramas, la forma en la

Hoy vamos a hablar de uno de estos ltimos, un modelo

Este artculo est dividido en dos partes (enlace a la

Entendiendo este artculo

Como repaso rpido recordemos lo siguiente:

El trmino HEAD referencia al ltimo commit existente

Llamaremos origin al servidor central donde estar

Usaremos la nomenclatura estndar al nombrar ramas:

Y poco ms. Sabido esto podemos empezar... :)

El modelo de ramas acertado de Git

O como se llama en ingls A successful Git branching

Creado por Vincent Driessen, es un modelo de flujo de

A continuacin vamos a ir explicando cada uno de estos

La rama master es la nica rama existente que nos

Esta rama (sincronizada en todo momento con

origin/master) tiene como objetivo ser el contenido

Como podemos ver, cada commit (ilustrado por las

No se va a desarrollar desde esta rama en ningn

Esta rama funciona paralelamente a la master. Si la

desarrollo del proyecto hasta el ltimo commit realizado.

Cuando esta rama adquiera estabilidad y los

Esto ser lo que cree una nueva versin de nuestro

Las ramas de features

Que varias personas trabajen sobre la misma rama es

potencia de las ramas de Git.

Cada vez que necesitemos programar una nueva

Estas ramas pueden tener cualquier nombre que no

Ya que develop contiene la ltima foto de nuestro

$ git checkout -b bug_1134 develop

Una vez finalizada la tarea, solo tendremos que integrar

Este flag obliga a Git ha generar un commit para el

merge. Con esto se evita que Git haga un

De esta manera, en todo momento en la historia del

Una vez integrada la rama en develop, podremos

$ git checkout develop

Por ltimo, estas ramas no tienen por qu estar

puede hacerse sin problemas.

Las ramas de lanzamiento

Como hemos dicho antes, el desarrollo del proyecto ha

Esto no se har directamente con un merge desde la

Este tipo de ramas sirve para poder liberar cuanto antes

Es decir, todo aquello que no tiene que ver directamente

La creacin de esta rama ser anloga a las de otros

tipos, teniendo en cuenta que tendr que prefijarse con

$ git checkout -b release-1.2 develop

Una vez terminada la preparacin de la siguiese, habr

Por ltimo, se crear un tag en el commit del master

Como se puede ver en el grfico, los cambios no slo se

integrarn en el desarrollo. Por ltimo, y dado que ya no

As pues, las instrucciones para finalizar una rama de

$ git checkout master

Como detalle adicional mencionar que en las ramas de

Si en este proceso se detectase un bug nuevo, se

Las ramas de bugs urgentes

Y por ltimo tenemos las ramas de bugs urgentes. Estas

Esta rama se crear a partir de master ya que

$ git checkout -b hotfix-1.1.2 master

Una vez corregido el fallo tendremos que integrar el

Tambin se tendr que integrar la correccin del bug en

el desarrollo de futuras versiones.

Los comandos necesarios para llevar a cabo la