Qué ramas necesitás de verdad en un proyecto real

Publicado el 2026-09-12 por frfrand

Los flujos de trabajo famosos resuelven problemas que quizá no tenés. Tres modelos, para qué sirve cada uno, y cómo elegir según cómo publicás y cuántos son.

Cuando alguien busca "cómo organizar las ramas", encuentra diagramas complejos con cinco tipos distintos. La mayoría fueron pensados para un contexto específico que quizá no es el tuyo.

Antes de elegir un modelo conviene contestar una pregunta: ¿cómo publicás?

Modelo 1: una sola rama

Todo el mundo trabaja sobre main. Las ramas existen pero duran horas o un día, y se integran enseguida.

Funciona muy bien cuando publicás seguido y tenés tests en los que confiás. Es lo que usan la mayoría de los equipos que despliegan varias veces por día.

Lo que requiere para no ser un desastre:

• Tests automáticos que corran en cada integración y en los que realmente confíes.
• Interruptores de funcionalidad: si algo no está listo, se integra apagado en vez de quedarse en una rama.

Eso último es lo que más cuesta adoptar y lo que hace viable el modelo. Permite integrar código incompleto sin que llegue a los usuarios.

Modelo 2: dos ramas

Una rama de integración (main) y una de producción.

• main recibe todo lo que va quedando listo, y se despliega solo a staging.
• Cuando se quiere publicar, se integra main en la rama de producción, y eso dispara el despliegue al sitio real.

Publicar es un merge. Volver atrás es un revert. Cualquiera del equipo entiende el estado del sistema mirando dos ramas.

Para un equipo de dos a diez personas que publica algunas veces por semana, este modelo es difícil de superar por relación entre simpleza y control. Es el que usamos nosotros.

Modelo 3: Git flow

El famoso, con ramas de desarrollo, de funcionalidad, de release, de hotfix y master.

Fue diseñado en 2010 para software con versiones: un programa que se descarga, donde conviven la 2.3 y la 2.4, y hay que poder parchear una versión vieja sin meter lo nuevo.

Si ese es tu caso (una librería, una aplicación de escritorio, algo instalado en clientes), Git flow resuelve problemas reales.

Si tenés una aplicación web donde la única versión que existe es la que está corriendo, Git flow agrega ceremonia sin resolver nada. El propio autor publicó años después una nota diciendo exactamente eso.

Cómo elegir, en una pregunta

¿Necesitás mantener versiones viejas en paralelo?

• Sí → Git flow o algo parecido.
• No, y publicás varias veces por día → una sola rama con interruptores.
• No, y publicás algunas veces por semana → dos ramas.

Detalles que importan más que el modelo

Nombres con prefijo. feature/, fix/, chore/. Permite filtrar y entender de un vistazo. Y si incluís el número del ticket, la trazabilidad sale gratis.

Borrar las ramas integradas. Un repositorio con ochenta ramas viejas es ruido puro. La mayoría de las plataformas lo hace solo al cerrar un pull request.

Proteger la rama de producción. Sin push directo, con revisión obligatoria. No por desconfianza: porque a las siete de la tarde cualquiera se equivoca de rama.

Ramas cortas. Esto importa más que todo lo anterior junto. Un modelo mal elegido con ramas de dos días funciona bien. El mejor modelo del mundo con ramas de un mes, no.

En ArduMaker cada despliegue se asocia a una rama, así que podés tener el mismo repositorio publicado dos veces en el mismo VPS: una desde main a staging y otra desde produccion al dominio real.