Hotfix Branch: qué es, cómo crear y usar en desarrollo móvil

¿Qué es Hotfix Branch?

Hotfix Branch es una rama temporal en Git que se crea para la corrección urgente de defectos críticos en un entorno de producción activo. A diferencia de las ramas feature, que se ramifican desde develop y viven varios días o semanas, el hotfix se crea desde main/master y existe exactamente el tiempo necesario para corregir el error.

El objetivo principal del hotfix es minimizar el tiempo entre la detección de un error crítico y su corrección en producción. El equipo no espera a que termine el sprint actual o el ciclo de lanzamiento, sino que publica un parche de inmediato. Esto es especialmente importante para aplicaciones móviles, donde un error crítico puede bloquear a los usuarios y provocar su abandono.

Según Google Play Console, el tiempo medio de revisión de una actualización en Google Play es de 2 a 24 horas. Para la App Store, la revisión exprés puede tardar de 1 a 4 horas. Las ramas hotfix permiten preparar la corrección antes de que finalice la moderación y lanzarla inmediatamente después de la aprobación.

Cómo funciona el Hotfix

El proceso de hotfix consta de tres pasos: crear una rama desde main, realizar la corrección y fusionar de vuelta en main y develop. La diferencia clave con una corrección normal es que el hotfix siempre se fusiona en ambas ramas, para que la corrección no se pierda en el próximo lanzamiento.

El equipo no debe introducir nueva funcionalidad ni refactorización en un hotfix. Solo una corrección puntual, mínimamente necesaria para resolver el problema crítico. Cualquier desviación de esta regla aumenta el riesgo de regresión y retrasa la publicación del parche.

Cuándo se necesita un Hotfix

Un hotfix es necesario en tres escenarios: un error crítico bloquea a los usuarios (crash, pérdida de datos), una vulnerabilidad de seguridad requiere cierre inmediato, o se ha roto la lógica de negocio crítica (pagos, autorización). Si el error no es crítico, se puede corregir dentro del ciclo de lanzamiento normal a través de develop.

Para aplicaciones móviles, un hotfix también puede incluir cambios en el servidor si la arquitectura permite activar funciones de forma remota (feature flags). En ese caso, la rama hotfix puede ser mínima o incluso no ser necesaria si la corrección se realiza del lado del servidor.

Modelos de ramificación y lugar del Hotfix

No todos los modelos de ramificación admiten ramas hotfix. El Git Flow tradicional incluye el hotfix como un tipo de rama completo, mientras que los enfoques más modernos (GitHub Flow, Trunk-based) manejan las correcciones urgentes de otra manera.

Git Flow y Hotfix

Git Flow es el único modelo donde el hotfix es un tipo de rama integrado al igual que feature y release. En Git Flow, un hotfix se crea desde main y, al finalizar, se fusiona tanto en main (con una etiqueta de versión) como en develop. Esto garantiza que la corrección no se pierda en el próximo lanzamiento.

GitHub Flow y Trunk-based

GitHub Flow no utiliza un tipo de rama separado para hotfix. En su lugar, el desarrollador crea una rama feature normal desde main, realiza la corrección y abre un Pull Request. Tras la revisión y las comprobaciones de CI, la rama se fusiona en main y se despliega inmediatamente. La ventaja es la simplicidad; la desventaja es la falta de un canal específico para correcciones urgentes.

El desarrollo Trunk-based maneja los hotfix mediante confirmaciones directas en main (para casos críticos) con revisión obligatoria posterior. Este enfoque requiere una alta disciplina del equipo y pruebas automáticas fiables, ya que los cambios llegan a producción instantáneamente.

Cómo crear un Hotfix Branch

Crear un hotfix comienza cambiando a la rama principal y creando una nueva rama con el prefijo hotfix/. Veamos el proceso paso a paso con el ejemplo de la corrección de un error crítico en una aplicación móvil.

Crear una rama desde main

Primer paso: cambiar a main y asegurarse de que la rama esté actualizada. Luego crear una rama hotfix con un nombre claro que refleje la naturaleza de la corrección.

# Cambiar a main y obtener los últimos cambios
git checkout main
git pull origin main

# Crear una rama hotfix
git checkout -b hotfix/crash-on-login

Después de crear la rama, se puede realizar la corrección. Es importante recordar: un hotfix debe contener un número mínimo de cambios. No se debe refactorizar código ni añadir nuevas funciones, solo la corrección puntual que resuelve el problema.

Confirmar la corrección

La confirmación (commit) en un hotfix debe tener un mensaje informativo que describa claramente el problema y su solución. Formato: tipo(ámbito): descripción breve + enlace a la tarea en el tracker.

# Añadir los archivos modificados
git add src/ui/login/LoginActivity.kt

# Crear un commit con descripción
git commit -m "fix(login): handle null intent on activity resume

Fixes CRASH-142: NullPointerException when LoginActivity
receives onNewIntent after being destroyed by system"

El mensaje de confirmación debe contener una descripción del problema y un enlace a la tarea. Esto facilita la búsqueda en el historial y ayuda a los compañeros a entender qué se corrigió y por qué. Para proyectos móviles, también se suele indicar la versión de la aplicación donde se encontró el error.

Fusión en main y develop

El paso final es fusionar el hotfix de vuelta en main (con una etiqueta de nueva versión de parche) y en develop (para que la corrección se conserve en el próximo lanzamiento). Primero se fusiona en main con una etiqueta, luego en develop.

# Fusionar en main y crear una etiqueta
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# Fusionar en develop
git checkout develop
git merge --no-ff hotfix/crash-on-login

# Enviar los cambios al servidor
git push origin main --tags
git push origin develop

La bandera --no-ff garantiza la creación de una confirmación de fusión, incluso si el hotfix podría haberse aplicado mediante fast-forward. Esto preserva la información de que se realizó una corrección de emergencia y simplifica el análisis del historial en el futuro.

Diferencia entre Hotfix, Feature y Release

Un hotfix se diferencia fundamentalmente de las ramas feature y release en cuanto a objetivo, tiempo de vida y reglas de fusión. Comprender estas diferencias es fundamental para organizar correctamente los procesos Git en un equipo.

Una rama feature está destinada a nueva funcionalidad. Vive desde varios días hasta varias semanas, se crea desde develop y se fusiona de vuelta en develop. Una feature puede contener múltiples confirmaciones, incluidas experimentales, que posteriormente se comprimen mediante squash o rebase.

Una rama release prepara un lanzamiento para su publicación. Se crea desde develop, en ella se corrigen errores encontrados durante la estabilización y no acepta nueva funcionalidad. Al finalizar, la release se fusiona en main (con etiqueta) y develop.

Un hotfix, en cambio, se crea y fusiona directamente con main, saltándose develop (aunque después de la corrección se sincroniza también con develop). Contiene una cantidad mínima de cambios y existe durante un tiempo mínimo. Mientras que las ramas feature o release pueden posponerse hasta el próximo ciclo, un hotfix no.

Para el desarrollo móvil, esta distinción es especialmente importante: la App Store y Google Play permiten publicar versiones de parche por separado de los lanzamientos principales. La rama hotfix garantiza que un lanzamiento de parche no se mezcle con funcionalidades inacabadas.

Errores típicos al trabajar con Hotfix

Los errores al trabajar con hotfix pueden anular las ventajas de la corrección urgente. Veamos los cinco problemas más frecuentes que surgen en equipos que usan Git Flow.

• Crear un hotfix desde develop — si un hotfix se crea desde develop, pueden incluirse funcionalidades inacabadas en el parche. El hotfix debe crearse solo desde main para garantizar que solo se incluya código estable en la corrección.
• Varias correcciones en un mismo hotfix — cada corrección debe estar en su propia rama hotfix. Mezclar varios errores en una misma rama complica la revisión del código, aumenta el riesgo de regresión y dificulta la reversión si es necesario.
• Omitir la fusión en develop — si un hotfix no se fusiona en develop, la corrección se perderá en el próximo lanzamiento. El equipo descubrirá que el mismo error ha vuelto a aparecer y tendrá que corregirlo de nuevo.
• Etiqueta de versión incorrecta — un hotfix debe recibir un incremento de parche (v2.3.0 → v2.3.1), no uno menor (v2.4.0) o mayor (v3.0.0). Violar el versionado semántico rompe el sistema de compilación y confunde a los usuarios.
• Falta de comprobaciones CI — incluso un hotfix urgente debe pasar las pruebas automáticas. Saltarse el CI aumenta el riesgo de introducir un nuevo error. Se recomienda tener un pipeline separado para las ramas hotfix con comprobaciones aceleradas.

Cada uno de estos errores provoca un retraso en la publicación del parche o la aparición de nuevos problemas en producción. Los equipos deberían documentar las reglas de trabajo con hotfix en CONTRIBUTING.md y automatizarlas mediante comprobaciones CI/CD.