Git flow son utilidades que se basan en el artículo A successful Git branching model y se integran a Git para permitir un flujo de desarrollo más orgánico, muy parecido a cómo van evolucionando los proyectos. En este artículo comparto la forma en que Gitflow me ha ayudado a tener un mejor control de versiones.
Instalación
Gitflow está disponible para Linux, Mac y Windows, para instalarlo podemos seguir las intrucciones en la documentación .
Por el momento sólo lo he instalado en Windows y creo que la mejor forma es usando mysgit.
Iniciar git-flow
Cualquier repositorio Git puede cofigurarse para utilizar git flow con el comando
$ git flow init
El script nos hará algunas preguntas las cuales es recomendable dejar con los valores por default.
Si trabajamos en un proyecto existente, después de clonar el repositorio debemos generar la ramificación develop a partir de origin/develop. Y luego iniciar git flow
$ git checkout -b develop origin/develop
$ git flow init
Nuevas caraterísticas o features
La mayor parte del tiempo estaremos trabajando sobre ramificaciones llamadas features, las cuales permiten ir desarrollando nuevas características e integrarlas posteriormente a develop.
Para comenzar una nueva característica ejecutamos:
$ git flow feature start autenticacion
Nos creará una ramificación llamada feature/autenticacion sobre la cual desarrollaremos y guardaremos revisiones hasta que los objetivos de la característica se cumplan.
Para concluir la característica ejecutamos:
$ git flow feature finish autenticacion
Gitflow unirá nuestra característica a la ramificación de desarrollo y despues la eliminará. Una de las ventajas de usar git-flow es que nuestras revisiones no formarán un línea aburrida sino que cada feature podrá identificarse visualmente por que se desprende de develop y vuelve a integrarse con un mensaje haciendo referencia a la ramificación que se unió
Renombrar feature
Si despues de agregar nuestro feature nos damos cuenta que no tiene el nombre adecuado, podremos renombrar la ramificación usando
$ git branch -m feature/nuevo-nombre
Lo importante es conservar el prefijo feature/ para que Git flow siga considerandola una característica.
Modificar mensaje de revisión
Al ejecutar git flow feature finish automáticamente se genera un mensaje de revisión como el siguiente:
Merge branch feature/autenticacion into develop
Si queremos modificar el mensaje, para decir que por ejemplo la nueva característica cierra la incidencia 195, podemos usar
git commit --amend -m "Merge feature/autenticacion closes #195"
Desarrollo de varias características a la vez
Tener varias características activas es común en proyectos colaborativos y lo importante es integrar el trabajo de cada desarrollador.
Git flow nos permite tener varios features al mismo tiempo. Todos ellos se desprenden de develop y podrán volver a unirse en un futuro, por lo que es inevitable que algunas características no estén actualizadas. Si nos encotramos, por ejemplo, desarrollando una característica, pero otro desarrollador introdujo cambios a develop nuestra característica ya no está actualizada. Para incluir los cambios en nuestra característica podemos ejecutar:
$ git pull origin develop
$ git merge develop --no-ff
Git flow integrará los cambios a nuesta ramificación para seguir desarrollando y posteriormente terminar la característica.
Si queremos evitar conflictos a la hora de integrar las características a la ramificación de desarrollo es recomendable que las características esten bien delimitadas y contengan pocas revisiones.
Lanzamiento de Nuevas Versiones o releases
Si hemos agregado varias características y nuestro proyecto está listo para lanzar una nueva versión utilizaremos
$ git flow release start 1.0
El comando generará una ramificacion llamada release/1.0 que por default se coloca en develop.
Para terminar la versión ejecutamos
$ git flow release finish 1.0
Si el comando corre sin errores, tendremos una nueva etiqueta llamada 1.0, además de master y develop alineadas.
### Generar nueva versión con base diferente a develop
En ocasiones develop está muy lejos de master y pudiera no cumplir con todos los requerimientos para publicar una nueva versión. Git flow nos permite seleccionar una revisión intermedia para marcar la versión. El comando es el siguiente:
$ git flow release start 1.1 <ref>
Después de terminar el release, master estará mas cerca de develop y ambos cotendrán los cambios realizados en la etiqutea 1.1.
Cambio de versión
Generalmente los proyectos de desarrollo contienen archivos especiales que determinan la versión del proyecto, por ejemplo: *.gemspec, styles.css o grails.properties. Idealmente dichos archivos sólo se modificarán en los releases. También podemos hacer cambios al archivo README o a la configuración global, sin embargo, si tratamos de corregir algún error, debemos utilizar hotfixes.
Cabe mencionar que para nombrar una versión es recomendable utilizar versiones semánticas.
Correcciones urgentes o hotfix
Después de publicar nuestro proyecto podremos seguir desarrollando, pero si surgen errores en la versión de producción, tendremos que utilizar el comando
$ git flow hotfix start 2.3.1
Git flow nos generá una ramificación llamada hotfix/2.3.1 la cual se desprenderá de master, es decir, de nuestra versión en producción.
El nombre de la ramificación es el de la etiqueta que se creará cuando terminemos nuestras correcciones. Siguiendo las versiones semánticas nuestro hotfix deberá incrementar la versión en el tercer digito, pues se trata de un cambio pequeño, por ejemplo si estamos en la versión 2.3, nuestra corrección debiera ser 2.3.1.
Para terminar el hotfix ejecutamos:
$ git flow hotfix finish 2.3.1
Alias
Los comandos de git flow son muy extensos, pero utilizando los alias de Git podemos ahorrarnos algunos caracteres:
$ git config --global alias.feat "flow feature"
$ git config --global alias.release "flow release" $ git config --global alias.fix "flow hotfix"
Conclusiones
Gitflow significa una dependecia más para el desarrollo por lo que probablemente en proyectos muy pequeños no sea tan relevante su uso. Finalmente si el proyecto se extiende, podemos integrar git flow en cualquier punto de desarrollo.
Hasta ahora he tenido una buena experiencia usando Gitflow, cabe mencionar que en los proyectos que los he usado han sido medianos (100..1000 revisiones) y con pocos colaboradores.