Release Branch en Git — qué es, propósito y flujo de trabajo

Qué es una Release Branch en Git

Release Branch (rama de lanzamiento) es una rama temporal en Git Flow, creada a partir de develop cuando el equipo decide que el conjunto actual de funciones está listo para su publicación. Existe exactamente el tiempo que dura la preparación final del lanzamiento, desde unas horas hasta varios días.

El propósito principal de la rama release es congelar un conjunto específico de funciones para el lanzamiento sin detener el desarrollo de las siguientes versiones. Mientras la rama release se prepara para su publicación, otros desarrolladores pueden seguir fusionando ramas feature en develop para el próximo lanzamiento.

En la rama release no se crean nuevas funciones, solo correcciones de errores, actualización de la versión de la aplicación, localización y documentación. Una vez completado todo el trabajo, la rama release se fusiona en main (marcada como lanzamiento) y de vuelta en develop (para que las correcciones lleguen a versiones futuras).

Según Atlassian, 2024, las ramas release son críticamente importantes para proyectos con ciclos de lanzamiento regulares: garantizan previsibilidad y estabilidad en el proceso de publicación.

Ciclo de vida de la rama release

El ciclo de vida de la rama release, desde su creación hasta su eliminación, incluye varias etapas. Comprender cada etapa ayuda al equipo a sincronizar acciones y evitar errores.

1. Creación — desde el último commit de develop se crea una rama con el nombre release/2.5.0. develop continúa aceptando ramas feature para la siguiente versión.
2. Preparación — en la rama release se actualiza la versión de la aplicación en build.gradle, Info.plist y otros archivos de configuración.
3. Corrección de errores — se corrigen los errores críticos encontrados durante las pruebas finales. Solo errores, sin nuevas funciones.
4. Pruebas finales — el equipo de QA realiza pruebas de regresión en la rama release. Los nuevos errores se envían para corrección en la misma rama.
5. Fusión en main — la rama release se fusiona en main con la bandera --no-ff. Se crea la etiqueta de lanzamiento: v2.5.0.
6. Fusión en develop — la rama release se fusiona de vuelta en develop para que las correcciones del lanzamiento lleguen al desarrollo actual.
7. Eliminación — la rama release se elimina local y remotamente, ya que su tarea está completada.

El paso 6 — la fusión inversa en develop — a menudo se olvida, pero es críticamente importante. Sin ella, las correcciones realizadas en la rama release no llegarán a develop, y los mismos errores podrían aparecer nuevamente en el próximo lanzamiento.

Duraciones típicas de las etapas de la rama release

El tiempo de vida de la rama release depende de la complejidad del lanzamiento y la calidad del código en develop. En promedio, la preparación toma de 2 a 5 días hábiles para una aplicación móvil de tamaño mediano.

Qué se hace en la rama release

En la rama release se realiza un conjunto estrictamente limitado de tareas. Cualquier desviación de esta lista viola el modelo Git Flow y crea riesgos para la estabilidad del lanzamiento.

La regla de prohibición de nuevas funciones es la más importante en la rama release. Si una función no llegó a tiempo para el lanzamiento, espera al siguiente ciclo. Intentar introducir una función incompleta en la rama release es la principal causa de incumplimiento de plazos y errores en producción.

Actualización de versión en un proyecto móvil

En la rama release se actualiza obligatoriamente el número de versión de la aplicación. Para Android, son los campos versionCode y versionName en build.gradle; para iOS, CFBundleShortVersionString en Info.plist.

// build.gradle (app-level) — actualización de versión en la rama release
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// Para iOS — actualización de Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Diferencias entre release y hotfix

Los desarrolladores principiantes a menudo confunden las ramas release y hotfix, aunque su propósito es fundamentalmente diferente. Elegir el tipo de rama incorrecto puede retrasar una corrección crítica o interrumpir el proceso de lanzamiento.

• Origen — release se crea desde develop, hotfix desde main. Esta es la principal diferencia que determina todo lo demás.
• Urgencia — release es planificado: el equipo decide cuándo comenzar la preparación. Hotfix es urgente: un problema en producción requiere corrección inmediata.
• Contenido — release puede incluir varias correcciones y actualización de versión. Hotfix contiene solo una corrección crítica.
• Fusión — release se fusiona en main y develop. Hotfix también se fusiona en main y develop, pero de forma prioritaria.
• Tiempo de vida — release vive de 1 a 7 días. Hotfix vive de 30 minutos a 1 día.

Si se encuentra un error durante la preparación del lanzamiento (en la rama release), es una corrección normal. Si se encuentra un error en producción (en main), es un hotfix y se crea desde main, incluso si la rama release ya existe.

Reglas de nomenclatura de ramas release

Un estándar unificado de nomenclatura de ramas release simplifica la navegación por el repositorio y permite que los sistemas CI/CD detecten automáticamente que una rama pertenece al proceso de lanzamiento.

• release/X.Y.Z — formato estándar de Git Flow, donde X.Y.Z es la versión del lanzamiento. Ejemplo: release/2.5.0.
• release/nombre — formato alternativo con un nombre clave del lanzamiento. Ejemplo: release/merlin.
• release/fecha — formato con la fecha del lanzamiento. Se usa raramente, ya que la versión es más importante que la fecha. Ejemplo: release/2024-12-01.

El formato release/X.Y.Z es el preferido, ya que vincula explícitamente la rama con el número de versión que se asignará al lanzamiento. Esto simplifica la búsqueda y el procesamiento automático mediante scripts de CI/CD.

Estrategia de fusión inversa en develop

La fusión inversa (merge back) de la rama release en develop es una de las operaciones más importantes y, al mismo tiempo, una de las que más frecuentemente se omiten. Sin ella, todas las correcciones realizadas en la rama release se quedan solo en la versión de lanzamiento y no llegan al siguiente ciclo de lanzamiento.

El proceso de fusión inversa se realiza después de que la rama release ya se ha fusionado en main. Primero, release se fusiona en develop, luego se elimina. Esto garantiza que develop contenga todas las correcciones realizadas durante la preparación del lanzamiento.

Después de la fusión inversa, pueden surgir conflictos, especialmente si ya han aparecido nuevas ramas feature en develop que modificaban los mismos archivos. El desarrollador responsable del lanzamiento resuelve estos conflictos y sube develop al servidor.

Algunos equipos usan rebase en lugar de merge para la fusión inversa, para mantener un historial lineal. Sin embargo, merge es más seguro para develop, ya que no reescribe el historial de commits que otros desarrolladores ya podrían estar utilizando.

Ejemplos de comandos para trabajar con release

Veamos el ciclo completo de trabajo con una rama release: desde la creación hasta la eliminación después de un lanzamiento exitoso de una aplicación móvil versión 2.5.0.

# 1. Crear rama release desde develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Actualizar versión y correcciones
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Corregir errores (solo bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Enviar rama release al servidor
git push origin release/2.5.0

# 5. Fusionar release en main
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. Fusión inversa en develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Eliminar rama release
git branch -d release/2.5.0
git push origin --delete release/2.5.0

Los comandos 5 y 6 — la doble fusión — son críticamente importantes. Primero, main recibe el código de lanzamiento y la etiqueta, luego develop se sincroniza con las correcciones de release. Si se omite el paso 6, las correcciones del lanzamiento no llegarán al siguiente ciclo de desarrollo.

Automatización del proceso de lanzamiento

Para proyectos móviles con lanzamientos regulares, el proceso de crear una rama release y actualizar la versión se puede automatizar mediante scripts de CI/CD. GitHub Actions permite crear un workflow que, al hacer clic en un botón, crea una rama release con actualización automática de versión.

Para proyectos móviles con lanzamientos regulares, el proceso de crear una rama release y actualizar la versión se puede automatizar mediante scripts de CI/CD. GitHub Actions permite crear un workflow que, al hacer clic en un botón, crea una rama release con actualización automática de versión.

# GitHub Actions — automatización de la creación de rama release
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}