Por qué existen las ramas y los merge
Publicado el 2026-09-12 por frfrand
Una rama es un puntero de 41 bytes, y eso explica por qué Git cambió la forma de trabajar en equipo. Qué es realmente un conflicto, y la diferencia entre merge y rebase sin religión.
Antes de Git, crear una rama era un operativo. En algunos sistemas implicaba copiar el proyecto entero en el servidor y podía tardar minutos. La consecuencia cultural fue que casi nadie ramificaba: se trabajaba todo sobre el tronco y se rezaba.
Git cambió eso por una decisión de diseño muy simple.
Una rama es un puntero
Literalmente:
$ cat .git/refs/heads/feature-login a3f91c2e8d4b7a6f9c1e2d3b4a5f6e7d8c9b0a1f
Eso es la rama entera. Un archivo con un hash adentro. 41 bytes.
Crear una rama es escribir ese archivo. Por eso es instantáneo, por eso no ocupa espacio, y por eso el flujo de trabajo de Git te empuja a crear una para cada cosa.
Cuando hacés un commit estando en esa rama, el archivo se actualiza con el hash nuevo. La rama "avanza". Nada más.
Qué es realmente un conflicto
Hay una idea equivocada muy extendida: que un conflicto significa que Git no pudo fusionar.
Git fusiona automáticamente casi todo. Si vos tocaste el archivo A y otra persona el archivo B, no hay nada que decidir. Si los dos tocaron el mismo archivo pero en partes distintas, tampoco.
Un conflicto aparece sólo cuando dos personas cambiaron las mismas líneas de otra forma. Ahí Git podría elegir una, y se niega, porque elegir mal es peor que preguntar.
Ver un conflicto no es una falla del proceso: es la herramienta avisándote que hay una decisión humana pendiente. Los equipos que tienen conflictos todo el tiempo no tienen un problema de Git: tienen ramas que viven demasiado y tocan lo mismo.
Merge y rebase, sin religión
Las dos integran el trabajo de una rama en otra. Se diferencian en qué queda escrito después.
merge crea un commit nuevo con dos padres. La historia queda tal como pasó: dos líneas que se separaron y se juntaron. Es honesto y no reescribe nada.
rebase toma tus commits y los vuelve a aplicar arriba de la otra rama, como si los hubieras hecho después. La historia queda en línea recta y se lee mejor. Pero son commits nuevos, con hashes nuevos: los originales quedan huérfanos.
De ahí sale la única regla que importa de verdad:
No rebases una rama que otras personas ya tienen. Sus copias siguen apuntando a los commits viejos, y al intentar integrar van a aparecer duplicados y confusión.
Sobre tu propia rama, antes de compartirla, rebase es excelente: te deja limpiar commits intermedios de tipo "arreglo", "ahora sí" y "vuelvo atrás".
Una combinación que funciona muy bien en equipos: rebase para ordenar tu rama antes de abrir el pull request, merge para integrarla.
La parte que más ayuda y menos se dice
Casi todos los problemas con ramas se resuelven antes de que existan, con una costumbre: ramas cortas.
Una rama de dos días toca poco, se integra sin drama y casi nunca genera conflictos. Una rama de tres semanas se convierte en un proyecto de integración en sí misma.
Si una tarea es grande, la respuesta no es una rama larga: es partir la tarea en pedazos que se puedan integrar por separado, aunque queden detrás de un interruptor apagado.
