Definición
Una rama es una línea de trabajo paralela dentro de un repositorio de Git.
Partes del estado actual del proyecto, haces tus cambios en tu propia línea, y lo que está publicado no se ve afectado mientras tanto. Cuando terminas, esa línea se fusiona con la principal.
El problema que resuelve es sencillo de reconocer: sin ramas, todo el mundo escribe sobre lo mismo, y cualquier cosa a medias impide publicar cualquier otra cosa terminada.
Las operaciones
Crear rama. Sale del punto actual y no cuesta prácticamente nada — es una de las cosas que Git hace excepcionalmente bien.
Fusionar. Devolver los cambios a la rama principal.
Conflicto. Ocurre cuando dos ramas han cambiado las mismas líneas de un fichero y Git no puede decidir cuál vale. No es un error: es una pregunta. Hay que abrir el fichero, quedarse con lo correcto y resolverlo.
Y aquí está el dato práctico que evita casi todo el dolor: los conflictos crecen con el tiempo que la rama lleva abierta. Una rama de dos días se fusiona sola; una de dos meses es una tarde de trabajo y de riesgo.
Estrategias
Rama por funcionalidad. Una rama por cada cambio, fusionada al terminar. Es lo habitual y funciona bien casi siempre.
Trabajo sobre la principal. Ramas muy cortas —horas, no días— que se integran continuamente. Exige buenas pruebas automáticas y da la menor cantidad de conflictos.
Flujos con rama de desarrollo, ramas de versión y ramas de corrección. Estructuras completas pensadas para software que se publica por versiones. En un proyecto web que se despliega continuamente, suelen ser mucho más ceremonia de la necesaria.
Ejemplo práctico
En proyectos pequeños o de una sola persona, la tentación es no usar ramas: se trabaja directo sobre la principal y ya está.
Lo que aprendí: aun trabajando solo, la rama aporta algo concreto. Permite abandonar. Si empiezas un cambio grande y a mitad descubres que el enfoque no era bueno, con rama lo tiras y vuelves al estado limpio en un segundo. Sin rama, tienes que deshacer a mano un trabajo a medias mezclado con el código bueno.
Y aporta una segunda cosa igual de valiosa: poder arreglar algo urgente sin arrastrar lo que tienes a medias. Si a media tarea entra un fallo en producción, sales a una rama nueva desde lo publicado, corriges, despliegas y vuelves. Sin ramas, o publicas tu trabajo incompleto o no publicas el arreglo.
El segundo aprendizaje, sobre el tamaño: las ramas grandes son el problema, no las ramas. Una rama que toca cuarenta ficheros y lleva tres semanas es difícil de fusionar, difícil de revisar y difícil de probar. Ver revisión de código.
La regla práctica: una rama, un cambio, y fusionar en días, no en semanas. Si un trabajo es tan grande que no cabe en eso, casi siempre puede partirse en pasos que funcionan por sí solos.
Y una advertencia sobre lo que la rama no garantiza: fusionar sin conflictos no significa que funcione. Dos cambios pueden ser compatibles línea a línea e incompatibles en su lógica. Por eso las pruebas automáticas se ejecutan sobre el resultado de la fusión, no sobre la rama aislada. Ver CI/CD.
Errores comunes
- Ramas abiertas durante semanas.
- Trabajar siempre en la principal y no poder publicar nada aislado.
- Resolver un conflicto a la ligera y borrar el cambio de otro.
- Ramas que mezclan varios cambios sin relación entre sí.
- No borrar las ramas fusionadas, hasta perderse entre decenas.
- Nombres sin significado, del tipo «pruebas2».
- Adoptar un flujo de ramas complejo en un equipo de dos personas.
Cuándo usarlo
Siempre, incluso en solitario. El coste es cero y la libertad que da es real.
La regla que resume todo lo demás: si tu rama lleva más de una semana abierta, el problema ya no es la rama — es el tamaño del cambio.
