Controlar las versiones de tu código y organizar las ramas de Git no es un capricho de equipos grandes: es lo que separa un despliegue tranquilo de una caída en producción a las 3 a.m. Aquí aprenderás cómo aplicar Semantic Versioning y Gitflow en proyectos Python para liberar cambios de forma ordenada, identificar releases estables y reaccionar rápido ante errores. Es útil si desarrollas, despliegas o coordinas entregas con otros programadores.

¿Qué es el versionamiento semántico y cómo se lee?

El Semantic Versioning (o SemVer) es un sistema que organiza las versiones de tu aplicación usando tres números separados por puntos, por ejemplo 1.0.0. Cada número cuenta una historia distinta sobre lo que cambió en el código.

¿Qué significa cada número de la versión?

• Major (el primero, 1.x.x): se incrementa cuando hay cambios que rompen compatibilidad. Si pasas de 1.0.0 a 2.0.0, estás avisando que la versión anterior ya no funciona con la nueva.
• Minor (el del medio, x.1.x): suma funcionalidades nuevas sin dañar lo anterior. Ideal para deploys de features pequeñas que no tocan base de datos ni piezas críticas.
• Patch (el último, x.x.1): corrige errores. Es la pieza que usas cuando algo falla en producción y no puedes esperar al próximo ciclo de release.

¿Cuándo subo el major y cuándo el patch? Sube el major si tu cambio rompe la versión anterior. Usa el patch para arreglar bugs urgentes en producción sin tocar el resto del flujo.

¿Cómo etiquetar versiones con git tag?

Una vez decides qué número subir, necesitas dejarlo registrado en el repositorio. Para eso existe el comando git tag, que crea etiquetas que tu sistema de deployment puede leer para traer una versión específica de la aplicación.

Un ejemplo concreto para crear y publicar la primera versión:

bash git tag -a 1.0.0 -m "Lanzamiento de la versión 1.0.0" git push --tags

La bandera -a agrega la etiqueta, -m añade el mensaje descriptivo y el git push la sube a GitHub o al servicio que uses. Con ese tag publicado, puedes referenciar tu aplicación en producción apuntando a una versión estable y dejar staging con una versión menos estable para pruebas.

¿Para qué sirve un git tag en deployment? Sirve para que tu pipeline traiga exactamente la versión del código que tú decidiste, sin depender del último commit. Apuntas al tag y despliegas con certeza.

¿Cómo organizar el flujo de trabajo con Gitflow?

El versionamiento semántico solo funciona bien si tu código está organizado. Aquí entra Gitflow, una estrategia para manejar varias ramas en paralelo y mantener releases estables mientras el equipo sigue desarrollando.

¿Qué hace cada rama en Gitflow?

• main (o master): contiene la versión productiva. Cada deploy a producción se taguea en esta rama.
• develop: la rama de desarrollo estable. Sale de main y recoge los cambios que el equipo va integrando. Debe mantenerse usable para que otros desarrolladores partan de ella.
• feature: nace desde develop cuando vas a construir algo nuevo, por ejemplo un login. Trabajas el cambio y, cuando está listo y estable, lo regresas a develop.
• hotfix: nace desde main cuando hay un error urgente en producción. Arreglas, mezclas de vuelta a main, despliegas y luego propagas el cambio también a develop.

¿Cuándo uso una rama feature y cuándo un hotfix?

Usa una rama feature cuando vas a sumar funcionalidad nueva: parte de develop, trabaja tranquilo y mezcla cuando esté probada. Usa hotfix cuando producción está fallando y no puedes esperar el ciclo normal de release: parte de main, arregla, despliega y luego sincroniza ese arreglo en develop para que no se pierda.

La lógica es simple: main siempre refleja lo que está vivo en producción, develop refleja lo que será la próxima entrega, y las ramas auxiliares (feature y hotfix) protegen ambas líneas mientras trabajas.

¿Cómo se conecta todo en el ciclo de release?

Imagina que tu equipo está construyendo el feature de login. Creas la rama desde develop, trabajas los cambios y, cuando termina, mezclas a develop. En paralelo, alguien reporta un bug crítico en producción: abres una rama hotfix desde main, corriges, mezclas a main, taguea una nueva versión patch (por ejemplo 2.0.1) y haces deploy. Ese mismo arreglo lo llevas también a develop para no perderlo.

Cuando se cierra el ciclo del release, mezclas develop con main, taguea una nueva versión minor o major según corresponda y despliegas. Así el login queda disponible en producción y arrancas el siguiente ciclo con una base limpia.

Este flujo te da algo muy valioso: probar y desarrollar en entornos separados sin arriesgar lo que ya está vivo. Ahora prueba aplicarlo: crea una aplicación nueva, agrégale etiquetas con git tag, maneja las versiones siguiendo SemVer y abre las ramas que tu sistema de deployment va a necesitar. ¿Cómo organizas tú las versiones en tus proyectos?