Git permite organizar el trabajo con ramas, pero decidir cuándo crearlas y cómo integrarlas requiere un flujo consistente. Git Flow propone una convención basada en ramas de larga duración y ramas temporales para funcionalidades, versiones y correcciones urgentes. En esta guía recorreremos el flujo en un repositorio de práctica y distinguiremos el modelo conceptual de la herramienta git-flow.[1][2]
Importante: Git Flow es una convención, no una función integrada en Git. La herramienta
git-flowautomatiza algunas operaciones, pero los merges y commits resultantes siguen siendo operaciones Git normales.[1][2]
1. Las ramas principales
Git Flow utiliza dos ramas principales:
main(llamadamasteren algunas configuraciones): contiene el historial de producción. Las versiones publicadas suelen marcarse con etiquetas, por ejemplo,v1.2.0.develop: reúne los cambios destinados a la siguiente versión. Las ramas de trabajo suelen partir de ella y volver a integrarse en ella.
El flujo se completa con ramas temporales. Sus prefijos se configuran al inicializar git-flow y pueden variar; los valores habituales son feature/, release/ y hotfix/.[1][2]
| Tipo de rama | Se crea desde | Se integra en | Propósito |
|---|---|---|---|
feature/* | develop | develop | Desarrollar una funcionalidad aislada. |
release/* | develop | main y develop | Preparar una versión y propagar los ajustes finales. |
hotfix/* | main | main y develop | Corregir urgentemente una versión de producción. |
2. Preparar el repositorio
Primero se crea el repositorio y se realiza un commit inicial. Es importante que exista ese commit: antes de él, las ramas todavía no tienen un historial normal que listar.
git init -b main
# Crear archivos iniciales y confirmarlos
git add README.md
git commit -m "Añade README inicial"
git switch -c develop
git flow init
Durante git flow init, se aceptan los nombres de ramas y prefijos que proponga la herramienta, o se especifican otros acordes con el proyecto. Si se crea develop antes del primer commit, main puede no quedar como una rama normal con historial; en ese caso, después del commit inicial se puede crear explícitamente con git branch main.
Para inspeccionar ramas e historial sin abrir el paginador:
git --no-pager branch
git --no-pager log --oneline --graph --decorate --all
git status --short --branch
3. Desarrollar una funcionalidad
Una funcionalidad nace desde develop. El comando start crea la rama y cambia a ella:
git flow feature start nombre-de-la-mejora
Se modifica el código, se revisan los cambios y se crea al menos un commit:
git diff
git add README.md
git commit -m "Añade la mejora"
Al terminar, se cierra la rama con:
git flow feature finish nombre-de-la-mejora
En la configuración practicada, el comando vuelve a develop, integra la feature —en el ejemplo fue un fast-forward— y elimina la rama local de feature. Conviene comprobar después el estado y el historial. El nombre pasado a finish es el nombre sin el prefijo feature/.
4. Preparar y publicar una versión
Una release parte de develop, que contiene el trabajo acumulado para la siguiente versión:
git flow release start 1.2.0
En release/1.2.0 se actualiza la versión del proyecto, se hacen ajustes finales y se confirman en commits. Después se finaliza la release:
git flow release finish -m Release-1.2.0 1.2.0
Al completarse, la release se integra en main, se crea una etiqueta de versión —por ejemplo, v1.2.0, si se configuró el prefijo v—, se vuelve a integrar en develop y se elimina la rama temporal. La etiqueta representa el punto publicado en producción; el back-merge permite que develop conserve los cambios hechos durante la preparación.[1][2]
La versión del ejemplo debe coincidir con el estado real del producto. No se debe copiar un número de versión de una práctica si el proyecto ya tiene una política de versionado distinta.
5. Corregir producción con un hotfix
Un hotfix parte de main, porque la corrección debe aplicarse sobre la versión que está publicada, no sobre cambios aún en desarrollo:
git flow hotfix start 1.2.1
Se corrige el problema, se confirma el cambio y se finaliza:
git add .
git commit -m "Corrige un problema de producción"
git flow hotfix finish -m Hotfix-1.2.1 1.2.1
El cierre integra la corrección en main y develop, crea la etiqueta de versión y elimina la rama temporal. Así, la corrección queda publicada y también estará presente en futuras releases.[1][2]
6. Un problema práctico: getopt y los mensajes de etiqueta en macOS
En una práctica con git-flow 0.4.1 instalado mediante Homebrew en macOS, git flow release finish integró la release en main y luego falló al crear la etiqueta con fatal: no tag message?. Además, al pasar un mensaje entre comillas con espacios, la herramienta mostró un error de getopt.
La solución comprobada fue instalar GNU getopt con Homebrew y anteponer su directorio bin al PATH de la terminal. Después, el cierre funcionó proporcionando un mensaje de etiqueta de una sola palabra mediante -m:
brew install gnu-getopt
export PATH="/opt/homebrew/opt/gnu-getopt/bin:$PATH"
git flow release finish -m Release-1.2.0 1.2.0
La ruta /opt/homebrew corresponde a una instalación habitual de Homebrew en Apple Silicon; debe verificarse en cada sistema con brew --prefix gnu-getopt. Si un finish falla después de haber realizado un merge, no se debe repetir a ciegas: primero hay que inspeccionar git status, las ramas, las etiquetas y el grafo de commits. Git Flow puede haber completado parte de la operación antes de detenerse.
7. Buenas prácticas y límites
- Comprueba la rama activa antes de modificar archivos:
git status --short --branch. - Revisa
git diffantes de preparar cambios y confirma commits con mensajes descriptivos. - Finaliza cada rama temporal con su comando correspondiente; no mezcles trabajo no relacionado en una release.
- Inspecciona etiquetas y merges después de finalizar una versión.
- Git Flow es una opción, no una obligación. Para equipos que despliegan continuamente, un modelo de ramas más simple puede resultar más adecuado.[3]
- La extensión
supportexiste en algunas distribuciones, pero puede estar marcada como experimental; no debe asumirse que tiene el mismo nivel de soporte que feature, release y hotfix.
Conclusiones
Git Flow hace explícito el recorrido de los cambios: las features se integran en develop, las releases estabilizan una versión y los hotfixes parten de producción para corregirla con rapidez. La herramienta reduce pasos manuales, pero no sustituye la comprensión de Git: ante errores, el historial, las ramas, las etiquetas y el estado del árbol de trabajo son la fuente de verdad.
📚 Fuentes consultadas
- Repositorio y documentación de git-flow AVH Edition - GitHub
- A successful Git branching model - Vincent Driessen
- Git Flow considered harmful - Adam Ruka
- Documentación oficial de git tag