Git y GitHub. Ramificaciones, flujo de trabajo y etiquetas

En el artículo anterior vimos una primera aproximación a las ramificaciones en git. En este artículo vamos a ver algunas técnicas para la gestión, el manejo y el trabajo de ramificaciones.

Pero, sobre todo, quiero incidir en la importancia de las ramificaciones en un sistema de control de versiones. Y, de nuevo, insistir en la utilidad de GIT para múltiples disciplinas de trabajo. Ya sea como desarrollador, escritor, diseñador… o muchas otras profesiones, este sistema puede ayudar a que te organices mucho mejor. Pero vayamos al lío…

Como usuarios de una aplicación o servicio, disfrutamos cuando recibimos una nueva versión. Pero, debemos pensar, las actualizaciones son fruto del constante desarrollo y, para que una nueva característica en una aplicación o servicio llegue a nosotros, es necesario utilizar las herramientas adecuadas y, por supuesto, un buen sistema de control de versiones es también principal para conseguir que esto ocurra.

Anteriormente vimos cómo crear una nueva rama, cómo fusionarlas y también aprendimos a resolver conflictos en esos procesos. Pero, dada la importancia de las ramificaciones, vamos a ver técnicas y herramientas para el trabajo con GIT.

Gestión de ramificaciones

El comando git branch

Hasta el momento, lo que habíamos realizado con este comando era única y exclusivamente la creación de una nueva rama con git branch nueva_rama. Sin embargo, este comando nos proporciona más opciones interesantes,

• Mostrar un listado de las ramas del proyecto. Para ello, ejecutaremos la orden git branch. En la siguiente captura de pantalla verás el resultado de ejecutarlo. Si te fijas, delante de una de las ramas vemos un * y, además, está en otro color. Esto nos indica que la rama señalada es la rama activa.

• Si ejecutamos la orden git branch -v, además de esto, nos mostrará el último commit que hemos realizado.

• Por otro lado, tenemos la opción de conocer cuáles de las ramas presentes están fusionadas, y cuáles no. Para ello, utilizaremos las ordenes git branch --merged y git branch --no-merged, para ver las ramas fusionadas y las no fusionadas, respectivamente.

Flujo de trabajo con ramificaciones

Supongamos que hemos desarrollado una aplicación y hemos liberado la versión 1.0. Ésta se encuentra en nuestro sistema de control de versiones. Tras la celebración posterior al éxito conseguido, xD, pongamos que decidimos incorporar una serie de mejoras a la aplicación.

La rama de desarrollo

Al pensar en esa nueva versión, la 2.0, decidimos, evidentemente, seguir utilizando nuestro sistema de control de versiones Git. Y para ello, creamos una nueva rama. Este nueva rama, sobre la que vamos incorporando las mejoras, no tiene porque ser completamente funcional en un principio. Aunque, finalmente, en el momento en que la fusionemos con la rama principal, sí deberá serlo, claro.

Esta rama de desarrollo, a su vez, puede tener pequeñas ramificaciones, bien para añadir nuevas características, o bien para intentar diferentes alternativas que, una vez aprobadas, se fusionarán.

La rama principal o rama de producción

Pero, ¿porque no editar directamente la rama principal? Nosotros nos las habíamos dado muy felices cuando liberamos la versión 1.0. Creíamos que habíamos hecho una aplicación libre de fallos. Pero, nuestra amiga Realidad, nos rescató y nos mostró que teníamos varios errores, fallos, bugs, bichitos…

Los usuarios de la versión 1.0, no tan felices por la aplicación, comenzaron una campaña para que resolviéramos esos errores, urgentemente… Menos mal que dejamos intacta la rama principal o rama de producción porque, de otra forma ¿cómo localizar el fallo en un código que ya hemos modificado?

De esta manera, cada error que un usuario de nuestra versión 1.0 nos reporta, se materializa en una nueva rama de la rama principal. Una vez resuelto el problema, la fusionaremos a ésta.

Es conveniente borrar estas ramas que, simplemente, sirven para corregir errores. Borrar una rama es sencillo: git branch -d ramaaborrar.

Fusión

Llegados a este punto, y una vez estamos seguros de que la rama de desarrollo es estable y podemos lanzarla a producción, realizamos la fusión.

Etiquetas

¿Y esto de las versiones?¿Como podemos llevar un control de la versión de nuestra aplicación, libro o lo que sea? En Git, al igual que en otros CMS, disponemos de etiquetas.

Las etiquetas nos sirven para lo que hemos visto hasta ahora, indicar dónde hemos liberado una versión, cambios importantes en el código, o lo que consideremos importante.

Trabajando con etiquetas…

Disponemos de una serie de herramientas que nos permiten trabajar con etiquetas:

• git tag lista las etiquetas existentes.
• git tag etiqueta crea una etiqueta ligera llamada etiqueta.
• git tag -a etiqueta -m "anotación" crea una etiqueta anotada llamada etiqueta con una anotación. Si no añades la opción -m, abrirá el editor de texto que tengas configurado.
• git show etiqueta muestra los datos asociados con la etiqueta etiqueta.
• git -s etiqueta -m "anotación" crea una etiqueta firmada con tu firma GPG.
• git tag -v etiqueta nos permite verificar una etiqueta. firmada. Debemos disponer de la clave GPG pública del autor para poder verificarla.

También es posible etiquetar un commit posteriormente.

Las etiquetas y los servidores remotos

Por último, indicar que la orden git push no sube las etiquetas a un servidor remoto, es necesario subirlas de forma explícita. Para ello utilizaremos alguna de las siguientes órdenes:

• git push origin etiqueta para subir una etiqueta en concreto.
• git push origin --tags para subir todas las etiquetas.

Conclusiones

Con esto hemos aprendido lo fundamental para el trabajo con Git. Sin embargo, esto no es más que el principio, hay mucho más para profundizar.

En el siguiente artículo comentaré sobre el uso de submódulos y algunas herramientas interesantes para trabajar con Git.