FLUJO DE TRABAJO EN EQUIPO CON GIT

Es importante que cuando varios desarrolladores trabajan en un mismo proyecto, versionado con Git, esté bien definido un flujo de trabajo y de ramificaciones. En este artículo vamos a ver un posible flujo de trabajo para un pequeño equipo de desarrolladores, que bien se puede seguir al pie de la letra o adaptar a las necesidades de cada uno.

Ya sabemos que Git es un sistema de control de versiones distribuido en el que cada desarrollador es un repositorio independiente, aunque en algún caso se cuente con un repositorio central, en el que el trabajo con ramas es extremadamente sencillo, pudiendo mantener a la vez distintas ramas abiertas, usándolas en diferentes momentos del desarrollo y fusionándolas con frecuencia. Dada la facilidad para trabajar con ramas en Git, hay que ser cuidadoso y no caer en el error de crear ramas descontroladamente haciendo que el repositorio resulte caótico.

Cuando se inicia un repositorio Git, se parte de la rama master sobre la que no se trabaja directamente. En ella se mantiene únicamente código estable que se usa para desplegar en producción, y se mantienen otras ramas sobre las que se desarrollan funcionalidades, se corrigen errores, se realizan pruebas, etc.

Lo primero, después de iniciar el repositorio, será crear una rama develop:

$ git checkout -b develop 

que será la rama donde estén reflejados los últimos cambios realizados, y que sirve como rama de integración con master. Cuando se decide que se ha llegado a un punto estable y que está listo para ser desplegado, se fusiona con la rama master y se etiqueta incluyendo un comentario que describa la situación:

$ git checkout master
$ git merge --no-ff develop
$ git tag -a v0.1 -m ‘primera versión 0.1’ 
$ git push origin master
$ git push origin v0.1

Cada fusión en la rama master genera una nueva versión en el proyecto.

Además de las dos ramas principales sobre las que se organiza el trabajo, se mantienen otras ramas secundarias feature y hotfix, cada una de ellas con propósito determinado, que ayudan en el trabajo en paralelo de todo el equipo de desarrollo. A diferencia de las ramas master y develop, las de feature y hotfix son temporales, siendo eliminadas al finalizar la tarea.

En las ramas feature se desarrollan nuevas características del proyecto, partiendo siempre de la rama develop:

$ git checkout -b feature-nueva develop 

e incorporando los cambios a la misma, eliminando posteriormente la rama:

$ git checkout develop
$ git merge --no-ff feature-nueva
$ git branch -d feature-nueva
$ git push origin develop

La vida útil de estas ramas feature está determinada por la del desarrollo de esa característica particular. Finalizado ese desarrollo se opta por fusionar con la rama develop o bien por eliminarla y descartarla.

Por último, las ramas hotfix se utilizan para corregir errores detectados en el código en producción, por lo que en este caso se parte de la rama master evitando de esta manera incluir cambios realizados en la rama develop que pueden no estar todavía estables:

$ git checkout -b hotfix-0.1.1 master 

Corregido el error, se integran los cambios de nuevo en la rama master generando una nueva versión del proyecto e incorporando los cambios también en la rama develop:

$ git checkout master
$ git merge --no-ff hotfix-0.1.1
$ git tag -a 0.1.1
$ git checkout develop
$ git merge --no-ff hotfix-0.1.1