Tutorial de Git: Gitflow o trunk-based, elegir un modelo de ramas

Git no impone ninguna organización. Te da las ramas que viste en el capítulo anterior, y eres tú quien decide cuáles existen, quién las crea y cuándo se fusionan. Esa decisión se llama modelo de ramas, y dos grandes familias se reparten el terreno: Gitflow y el trunk-based development. Este capítulo presenta los dos, con sus comandos reales, y explica en qué contexto se justifica cada uno.

En qué se ha convertido Gitflow

Gitflow lo describió Vincent Driessen en enero de 2010, en un artículo titulado A successful Git branching model. El modelo se adoptó de forma masiva, hasta convertirse en el reflejo por defecto de toda una generación de desarrolladores.

El 5 de marzo de 2020, su propio autor añadió una advertencia al principio del artículo. Merece la pena leerla antes de adoptar el modelo: para un equipo que practica la entrega continua, recomienda explícitamente un funcionamiento mucho más simple, del tipo GitHub Flow, en lugar de meter Gitflow con calzador. Precisa que Gitflow conserva todo su sentido para un software versionado de forma explícita, o del que hay que mantener varias versiones en producción a la vez.

Dicho de otro modo, la pregunta no es «¿Gitflow está bien o mal?», sino «¿qué entrego y a qué ritmo?».

Trunk-based development

El principio cabe en una frase: una sola rama de larga vida, main, en la que todo el mundo integra su trabajo muy a menudo, a través de ramas de duración muy corta.

Una rama vive unas horas, un día, rara vez más. Se fusiona en cuanto el trabajo es coherente, aunque la funcionalidad no esté terminada: lo que todavía no puede ver el usuario se oculta tras un indicador de funcionalidad (feature flag) en lugar de quedarse retenido en una rama. main es desplegable en todo momento, y es la integración continua la que garantiza esa propiedad.

# 1. partir de la última versión de main
git switch main
git pull --rebase

# 2. una rama corta, para una sola cosa
git switch -c fix/calcul-prix

# 3. trabajar, hacer commits
git commit -am "Corrige le calcul du prix TTC"

# 4. publicar y abrir una pull request
git push -u origin fix/calcul-prix

# 5. tras la revisión y el visto bueno de la CI, fusionar en main
git switch main
git merge --no-ff -m "Fusionne fix/calcul-prix" fix/calcul-prix
git branch -d fix/calcul-prix

Merge made by the 'ort' strategy.
 app.js | 1 +
 1 file changed, 1 insertion(+)
Deleted branch fix/calcul-prix (was 711bcbc).

*   d7cdba6 Fusionne fix/calcul-prix
|  
| * 711bcbc Corrige le calcul du prix TTC
|/  
* 5b45117 Ajoute app.js
* 38b7dc5 Ajoute la doc

La opción --no-ff fuerza un commit de fusión incluso cuando un simple avance habría bastado. El historial muestra así explícitamente que una rama existió y lo que contenía. Sin -m, Git abre el editor configurado en el capítulo 1 con un mensaje ya rellenado. En la práctica, son los botones Merge pull request de GitHub y Merge request de GitLab los que hacen este trabajo por usted.

Las versiones se marcan con etiquetas sobre main, sin rama dedicada:

git tag -a v1.0.0 -m "Première version publique"
git push origin v1.0.0

tag v1.0.0
Tagger: Damien Flandrin <dam@example.com>
Date:   Wed Sep 2 10:00:00 2026 +0000

Première version publique

Prefiere siempre la etiqueta anotada (-a con un mensaje) a la etiqueta ligera: registra el autor, la fecha y un comentario. Y no olvides el mensaje: sin -m, Git abre un editor, y en un entorno automatizado el comando falla.

error: there was a problem with the editor 'false'
Please supply the message using either -m or -F option.

Gitflow

Gitflow añade una segunda rama permanente y tres familias de ramas temporales.

Ten en cuenta que la rama de producción se llamaba master en el artículo de 2010. Como hoy los proveedores crean los repositorios sobre main, es ese nombre el que se usa aquí.

Gitflow a mano

No hace falta ninguna herramienta: el modelo no es más que una disciplina de ramas.

# crear la rama de integración, una vez por todas
git switch -c develop
git push -u origin develop

# una funcionalidad
git switch -c feature/livraison develop
git commit -am "Ajoute le calcul des frais de livraison"
git switch develop
git merge --no-ff -m "Fusionne feature/livraison" feature/livraison
git branch -d feature/livraison

# una versión
git switch main
git merge --no-ff -m "Version 1.2.0" develop
git tag -a v1.2.0 -m "Version 1.2.0"

*   876ffba Version 1.2.0
|  
| * 269874d Fusionne feature/livraison
|/| 
| * afcc714 Ajoute la livraison
|/  
*   d7cdba6 Fusionne correctif/prix
|  
| * 711bcbc Corrige le calcul du prix
|/  
* 5b45117 Ajoute app.js

Gitflow con la herramienta git-flow

Existe un juego de comandos que automatiza estos encadenamientos. El proyecto original ya no se mantiene, la que sí se mantiene es la edición AVH, disponible en la mayoría de gestores de paquetes con el nombre git-flow.

git flow init -d       # -d acepta todos los nombres por defecto

Using default branch names.

Which branch should be used for bringing forth production releases?
   - main
Branch name for production releases: [main] 
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Bugfix branches? [bugfix/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 
Hooks and filters directory? [/root/a8/.git/hooks] 

El ciclo de una funcionalidad se resume después en dos comandos:

git flow feature start facturation
# … trabajas y haces commits …
git flow feature finish facturation

Switched to branch 'develop'
Updating 5b45117..61c7618
Fast-forward
 facture.php | 1 +
 1 file changed, 1 insertion(+)
Deleted branch feature/facturation (was 61c7618).

Summary of actions:
- The feature branch 'feature/facturation' was merged into 'develop'
- Feature branch 'feature/facturation' has been locally deleted
- You are now on branch 'develop'

Y el de una versión, también en dos. git flow release finish fusiona en main, pone la etiqueta y luego lleva todo de vuelta a develop:

git flow release start 1.1.0
# … actualización del número de versión, últimas correcciones …
git flow release finish -m "Version 1.1.0" 1.1.0

*   1b1a31d Merge tag '1.1.0' into develop
|  
| *   48f5649 Merge branch 'release/1.1.0'
| |  
| | * eb133dd Prepare la version 1.1.0
| |/  
|/|   
* | 61c7618 Ajoute la facturation
|/  
* 5b45117 Ajoute app.js

Este grafo ilustra bien el reproche que se le hace al modelo: tres commits de fusión para una versión que solo contenía una funcionalidad.

Cuál elegir

Elige el trunk-based development si entregas una aplicación web o un servicio que despliegas a menudo, si solo hay una versión en producción a la vez, si tu equipo es pequeño y si tienes tests automatizados dignos de ese nombre. Es el caso de la gran mayoría de los proyectos web actuales, y es el modelo que conviene adoptar por defecto.

Elige Gitflow si publicas versiones numeradas que tus usuarios instalan, si tienes que mantener varias versiones en paralelo, si una fase de validación formal separa el fin del desarrollo de la puesta en producción, o si trabajas bajo una restricción normativa que exige trazabilidad por versión. Bibliotecas, aplicaciones de escritorio, software embebido, versiones instaladas en casa del cliente: ahí el modelo conserva toda su pertinencia.

Si empiezas en solitario, ni uno ni otro. Trabaja sobre main, crea una rama cuando pruebes algo incierto y pon una etiqueta cuando estés contento. Ya adoptarás un modelo el día en que seáis varios, y ese día el trunk-based es el más fácil de implantar.

Un último consejo: no adoptes un modelo porque tenga fama de serio. Un Gitflow aplicado por un equipo de dos personas que despliegan a diario produce ramas release vacías y fusiones inútiles. El buen modelo es el que se corresponde con tu manera de entregar.

Y ahora, ¿qué?

Ya tienes las bases de Git. A partir de aquí, tres direcciones merecen el desvío.

La integración continua primero, que es el complemento indispensable del trunk-based development: lanzar tus tests automáticamente en cada push. GitHub Actions y GitLab CI están integrados en esas plataformas y se configuran con un simple archivo YAML en tu repositorio.

Las solicitudes de fusión después, pull requests en GitHub, merge requests en GitLab. Son las que organizan la revisión de código en equipo, y son la puerta de entrada real hacia main en los dos modelos presentados aquí.

Por último, los comandos de rescate: git bisect para encontrar por dicotomía el commit que introdujo un bug, git cherry-pick para recuperar un commit concreto de otra rama y git worktree para abrir varias ramas en varias carpetas a la vez.

El índice completo sigue accesible desde el tutorial Aprender Git, y el resto de tutoriales del recorrido en el hub Desarrollo web.