Fusionar ramas en Git significa combinar los cambios de una rama secundaria con otra rama, normalmente main.
Este proceso se llama merge y es la operación central del trabajo en equipo con Git. Cuando terminas de desarrollar una función nueva, usas git merge para incorporar esos cambios al código principal.
El flujo básico de un merge
Antes de fusionar, necesitas estar posicionado en la rama que va a recibir los cambios. Esta distinción es crítica y es el error más común entre principiantes.
Supón que trabajas en el equipo de desarrollo de Liverpool. Tienes una rama llamada feature/descuentos-navidad y quieres llevar esos cambios a main. El flujo es el siguiente:
# 1. Regresa a la rama principal
git switch main
# 2. Asegúrate de que main está actualizado
git pull origin main
# 3. Fusiona la rama de trabajo
git merge feature/descuentos-navidad
Git toma todos los commits de feature/descuentos-navidad y los incorpora a main. Si no hay conflictos, el proceso termina automáticamente con un mensaje de confirmación.
Tipos de merge
Git realiza dos tipos principales de fusión.
| Tipo | Cuándo ocurre | Resultado |
|---|---|---|
| Fast-forward | main no ha cambiado desde que creaste la rama |
Git mueve el puntero hacia adelante sin crear un commit extra |
| Merge commit | Ambas ramas tienen commits nuevos | Git crea un commit de fusión que une las dos historias |
El fast-forward es el más limpio. El merge commit es el más frecuente en equipos reales, porque varias personas trabajan al mismo tiempo.
¿Qué es un conflicto?
Un conflicto ocurre cuando dos ramas modificaron exactamente las mismas líneas de un mismo archivo.
Git no puede adivinar cuál versión es la correcta. Por eso te pide que decidas tú de forma manual.
Imagina que en Bimbo dos desarrolladores editan el archivo precios.py al mismo tiempo. La desarrolladora Ana trabaja en feature/precio-pan y cambia la línea del precio del pan blanco. El desarrollador Luis trabaja en feature/precio-integral y cambia la misma línea con un valor diferente. Cuando alguien intenta fusionar ambas ramas, Git encuentra un conflicto.
Cómo luce un conflicto en el archivo
Cuando hay un conflicto, Git modifica el archivo afectado e inserta marcadores de conflicto. Estos marcadores son el formato estándar que debes aprender a leer:
<<<<<<< HEAD
precio_pan_blanco = 18.50
=======
precio_pan_blanco = 19.00
>>>>>>> feature/precio-integral
La sección entre <<<<<<< HEAD y ======= contiene el código de tu rama actual (la que recibe el merge, por ejemplo main).
La sección entre ======= y >>>>>>> feature/precio-integral contiene el código de la rama que estás fusionando.
Pasos para resolver un conflicto manualmente
Resolver un conflicto tiene exactamente cuatro pasos. Sigue este orden siempre.
Paso 1: Identifica los archivos en conflicto.
git status
Git lista los archivos con el estado both modified. Esos son los que necesitas editar.
Paso 2: Abre el archivo y edítalo.
Elimina los tres marcadores (<<<<<<<, =======, >>>>>>>) y deja únicamente el código correcto. Tú decides si conservas una versión, la otra, o combinas ambas.
Resultado final del archivo después de resolver:
precio_pan_blanco = 19.00
No debe quedar ningún marcador de conflicto en el archivo. Si queda uno solo, el código fallará.
Paso 3: Marca el conflicto como resuelto.
git add precios.py
Al hacer git add sobre el archivo corregido, le dices a Git que ya resolviste el conflicto en ese archivo.
Paso 4: Completa el merge con un commit.
git commit -m "Merge: resuelve conflicto en precio de pan blanco"
Git genera el commit de fusión y el proceso termina. Tu historial ahora refleja la unión de ambas ramas.
Ejemplo completo: equipo de FEMSA
El equipo de FEMSA tiene dos desarrolladores trabajando en el sistema de inventario.
Situación inicial:
maintiene el archivoinventario.pycon la variablestock_inicial = 500- Carlos crea
feature/ajuste-stocky cambia la línea astock_inicial = 480 - Diana crea
feature/conteo-fisicodesde el mismo punto y cambia la línea astock_inicial = 510
Carlos fusiona primero sin problemas:
git switch main
git merge feature/ajuste-stock
# Fast-forward exitoso
Diana intenta fusionar después:
git switch main
git merge feature/conteo-fisico
# CONFLICT (content): Merge conflict in inventario.py
# Automatic merge failed; fix conflicts and then commit the result.
Diana revisa el archivo y ve:
<<<<<<< HEAD
stock_inicial = 480
=======
stock_inicial = 510
>>>>>>> feature/conteo-fisico
Diana consulta con Carlos. Deciden que el conteo físico de Diana es el dato correcto. Diana edita el archivo:
stock_inicial = 510
Luego ejecuta:
git add inventario.py
git commit -m "Merge: usa stock del conteo físico (510 unidades)"
El historial queda limpio y documentado con la razón de la decisión.
Errores comunes
Error 1: Hacer merge desde la rama equivocada.
Si estás en feature/descuentos-navidad y ejecutas git merge main, traes los cambios de main a tu rama de trabajo, no al revés. Siempre verifica con git branch --show-current antes de hacer merge.
Error 2: Dejar marcadores de conflicto en el código.
Es común guardar el archivo sin borrar los marcadores <<<<<<< o >>>>>>>. El programa falla en tiempo de ejecución con errores de sintaxis. Revisa el archivo completo antes de hacer git add.
Error 3: Olvidar el git add antes del commit.
Después de editar el archivo con conflicto, muchos desarrolladores van directo a git commit. Git rechaza el commit porque el archivo no está marcado como resuelto. Siempre haz git add archivo primero.
Error 4: Hacer merge sin actualizar main primero.
Si no ejecutas git pull origin main antes del merge, puedes fusionar sobre una versión desactualizada. Esto genera conflictos innecesarios o sobreescribe trabajo de otros.
Comandos de referencia rápida
| Comando | Función |
|---|---|
git merge nombre-rama |
Fusiona la rama indicada en la rama actual |
git status |
Muestra archivos en conflicto (estado both modified) |
git add archivo |
Marca un conflicto como resuelto |
git merge --abort |
Cancela el merge y regresa al estado anterior |
git log --oneline --graph |
Visualiza el historial con las fusiones |
El comando git merge --abort es tu red de seguridad. Si en medio de un merge te das cuenta de que algo está mal, ese comando cancela todo y deja el repositorio como estaba antes. Úsalo sin miedo.
Buenas prácticas al fusionar
Fusiona main en tu rama de trabajo con frecuencia. Si tu rama lleva varios días sin actualizarse, los conflictos se acumulan y se vuelven más difíciles de resolver. Es mejor resolver conflictos pequeños cada día que un conflicto enorme al final.
Escribe mensajes de commit descriptivos en el merge. Un mensaje como "Merge: integra módulo de pagos con tarjeta" le dice a todo el equipo qué se fusionó y por qué. Evita mensajes genéricos como "merge" a secas.
Prueba el código antes de hacer el commit final. Después de resolver el conflicto y antes de ejecutar git commit, corre las pruebas del proyecto. Un conflicto resuelto de forma incorrecta puede compilar sin errores de Git pero romper la lógica del programa.