Controlar las versiones de tu código y organizar las ramas de tu repositorio son dos prácticas que marcan la diferencia entre un despliegue caótico y uno predecible. Comprender cómo funciona el versionamiento semántico junto con una estrategia de ramificación como GitFlow te dará la claridad necesaria para saber exactamente qué cambios van a producción y cuándo.
¿Qué es el versionamiento semántico y por qué importa?
El Semantic Versioning (o SemVer) es un sistema que estructura las versiones de tu código en tres números separados por puntos, por ejemplo 1.0.0 [0:10]. Cada número comunica el tipo de cambio realizado sin necesidad de revisar el código a fondo.
- Major version (primer número): se incrementa cuando los cambios rompen la compatibilidad con versiones anteriores. Pasar de
1.x.x a 2.0.0 indica que la versión dos ya no es compatible con la uno [0:30].
- Minor version (segundo número): se usa para agregar nuevas funcionalidades que no dañan las versiones previas. Por ejemplo,
1.2.0 significa que se incorporaron características nuevas sin alterar la base de datos ni provocar caídas en producción [0:52].
- Patch (tercer número): reservado para correcciones urgentes en producción. Si algo falla y no puedes esperar el ciclo completo de releases, incrementas este número, como
2.0.1, para aplicar un arreglo puntual [1:15].
Esta convención permite que cualquier miembro del equipo entienda de un vistazo la magnitud del cambio que se desplegó.
¿Cómo crear etiquetas de versión con git tag?
Para vincular el versionamiento semántico con tu repositorio de Git, existe el comando git tag [1:38]. Las etiquetas funcionan como marcas fijas que tu sistema de deployment puede referenciar para traer una versión específica de la aplicación.
¿Cuál es el flujo para crear y publicar un tag?
- Ejecutar el comando con la opción
-a para agregar y -m para el mensaje descriptivo:
bash
git tag -a v1.0.0 -m "Lanzamiento de la versión 1.0.0"
- Publicar la etiqueta en el repositorio remoto con
git push [1:50].
- Una vez publicada, puedes copiar ese tag y referenciar tu aplicación en producción con una versión estable, mientras que en staging trabajas con una versión en desarrollo [2:05].
¿Cómo organizar las ramas con GitFlow?
El versionamiento semántico cubre las versiones estables, pero tu aplicación siempre tiene cambios en curso. Para gestionar ese flujo constante se utiliza GitFlow, una estrategia de ramificación que define cuatro tipos de ramas principales [2:22].
¿Qué función cumple cada rama?
- Main (o Master): contiene el código que está en producción. Las versiones aquí siempre están tagueadas con su número semántico correspondiente [2:35].
- Develop: es la rama de desarrollo. Sale de Main y acumula los cambios que se han ido integrando. Debe mantenerse como una versión estable para que el resto del equipo pueda trabajar sobre ella [2:48].
- Feature: cuando necesitas crear algo nuevo, como un sistema de login, abres una rama desde Develop, realizas todos los cambios y, una vez estables, los mezclas de vuelta a Develop [3:05].
- Hotfix: si aparece un error urgente en producción, creas esta rama directamente desde Main. Aplicas la corrección, la mezclas de nuevo en Main y haces deploy de inmediato, sin esperar a que los features en desarrollo estén listos [3:25].
¿Cómo se sincronizan los cambios entre ramas?
Cuando un hotfix se aplica a Main, esos cambios no se copian automáticamente a Develop. Es necesario mezclarlos manualmente para que la rama de desarrollo también tenga la corrección [3:42]. Al finalizar un ciclo de releases, Develop se mezcla con Main, lo que pone a disposición en producción todas las funcionalidades nuevas, como el login del ejemplo [3:55].
Esta estructura garantiza que puedas desarrollar, probar y desplegar cambios de forma ordenada en entornos de pruebas y producción. Ahora es tu turno: crea una aplicación, agrégale etiquetas semánticas y configura las ramas de GitFlow para practicar este flujo completo.
