Merge — qué es, tipos de fusión y cómo funciona

¿Qué es Merge?

Merge (fusión) es una operación fundamental en Git que combina cambios de una rama (source) en otra (target). Como resultado de la fusión, la rama objetivo recibe todos los commits de la rama origen que aún no estaban en ella. Dependiendo de la situación, Git puede realizar el merge de tres formas diferentes.

El principal valor del merge es preservar el historial: el merge commit registra el hecho de la fusión de ramas, conservando información sobre cuándo y qué ramas se fusionaron. Esto facilita la auditoría de cambios, la búsqueda de regresiones y la comprensión de la cronología del desarrollo. En proyectos grandes, el merge commit es la forma estándar de integración de código.

Según GitLab Flow, los merge commits se utilizan en el 73% de los equipos que trabajan con Git. Los enfoques alternativos (rebase, squash) son preferidos por equipos orientados a un historial lineal. La elección de la estrategia depende del tamaño del equipo, la frecuencia de lanzamientos y las convenciones aceptadas en el proyecto.

Cuándo ocurre Merge

Merge es necesario cuando un desarrollador ha terminado de trabajar en una funcionalidad y quiere integrarla en develop o main. Un escenario típico: un desarrollador creó una rama de funcionalidad desde develop, trabajó en ella durante varios días, y durante ese tiempo aparecieron nuevos commits de otros miembros del equipo en develop. Antes de fusionar, es necesario combinar los cambios — y para eso se usa merge.

Sin merge, es imposible trabajar de forma colaborativa en un mismo código en Git. Cada vez que dos desarrolladores realizan cambios simultáneamente en una misma base de código, sus ramas divergen. Merge es la única forma de volver a unir estos cambios sin pérdida de datos.

Tipos de fusión en Git

Git admite tres tipos de merge, cada uno diseñado para su propio escenario. La elección del tipo de fusión afecta al historial de commits, la facilidad de reversión y la legibilidad del registro.

Fast-forward merge

Fast-forward ocurre cuando la rama objetivo no ha tenido nuevos commits desde que se creó la rama origen. En este caso, Git simplemente mueve el puntero de la rama objetivo hacia adelante, al último commit de la rama origen. El historial permanece lineal, sin merge commit.

# Fast-forward merge: develop no ha cambiado desde la creación de feature
git checkout develop
git merge feature/new-login

# Resultado: el puntero de develop se movió al final de feature
# No se ha creado ningún merge commit

Fast-forward es conveniente para ramas de corta duración donde un desarrollador trabajó solo. Pero este enfoque tiene un inconveniente: se pierde la información de que la rama existió — todos los commits parecen hechos directamente en develop.

Three-way merge

Three-way merge se ejecuta cuando ambas ramas tienen nuevos commits después del punto de divergencia. Git crea un merge commit separado con dos padres, que registra el hecho de la fusión de ramas. Este enfoque se recomienda para ramas de funcionalidad en el desarrollo en equipo.

# Three-way merge forzado con la bandera --no-ff
git checkout develop
git merge --no-ff feature/new-login

# Se ha creado un merge commit con el mensaje por defecto
# Puede establecer su propio mensaje mediante -m
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

La bandera --no-ff garantiza la creación de un merge commit, incluso si fast-forward es posible. Esta es una buena práctica para preservar la información de ramificación en un proyecto.

Squash merge

Squash merge comprime todos los commits de la rama origen en uno y lo aplica a la objetivo. El historial de la funcionalidad se pierde — un solo commit con todos los cambios termina en la rama. Esto es conveniente cuando los commits detallados en una rama de funcionalidad no aportan valor al historial general.

# Squash merge: todos los commits de feature se comprimen en uno
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

Squash es adecuado para borradores, ramas experimentales y situaciones en las que es importante mantener un historial limpio. La desventaja es que se pierde la conexión con los commits originales, lo que dificulta la reversión de cambios individuales.

Estrategias Ours y Theirs

Ours y Theirs son dos estrategias especiales de merge en Git. Ours ignora completamente los cambios de la rama origen, conservando solo lo que hay en la objetivo. Theirs, por el contrario, acepta la versión de la rama origen en cualquier conflicto. Estas estrategias son útiles al fusionar grandes volúmenes de código cuando se sabe de antemano qué versión debe prevalecer.

Cómo funciona Merge

El mecanismo de merge en Git se basa en la comparación de tres puntos: el ancestro común (merge base), el estado de la rama origen y el estado de la rama objetivo. Git encuentra el merge base — el último commit común a ambas ramas — y calcula qué cambios ocurrieron en cada rama después de la divergencia.

• Paso 1 — Git determina el merge base: el último commit presente en ambas ramas
• Paso 2 — Git construye dos diffs: del merge base a source y del merge base a target
• Paso 3 — Git intenta aplicar ambos conjuntos de cambios al merge base
• Paso 4 — Si los cambios no entran en conflicto — el merge se completa automáticamente
• Paso 5 — Si hay conflicto — Git se detiene y solicita resolución

Git utiliza un algoritmo de fusión trilateral que considera no solo las dos versiones del archivo comparadas, sino también su ancestro común. Gracias a esto, Git puede resolver automáticamente situaciones en las que los cambios en una rama no afectan áreas modificadas de la otra — incluso si ambos archivos fueron modificados.

Ejemplo de funcionamiento del merge

Consideremos un escenario: dos desarrolladores trabajan en diferentes archivos en una misma rama de funcionalidad. El primero modificó LoginActivity.kt, el segundo modificó ProfileFragment.kt. Cuando fusionan sus cambios, Git ve que los cambios afectaron a diferentes archivos y realiza el merge automáticamente, sin intervención humana.

Si ambos desarrolladores modificaron LoginActivity.kt, pero en diferentes métodos — Git también lo manejará automáticamente, fusionando los cambios línea por línea. Un conflicto solo surge si ambos modificaron las mismas líneas o si uno eliminó código que el otro modificó.

Resolución de conflictos en Merge

Un conflicto de merge ocurre cuando Git no puede fusionar automáticamente los cambios porque ambas ramas modificaron las mismas líneas de diferente manera. En este caso, Git marca las áreas conflictivas en los archivos y espera la resolución manual del desarrollador.

Las áreas de conflicto se marcan con marcadores especiales: <<<<<<< HEAD muestra el código de la rama objetivo, ======= es el separador, >>>>>>> source-branch muestra el código de la rama origen. El desarrollador debe elegir manualmente qué versión conservar o combinarlas.

# 1. Ejecutar merge y ver el conflicto
git merge feature/new-login
# Salida: CONFLICT (content): Merge conflict in LoginActivity.kt

# 2. Ver la lista de archivos con conflictos
git status
# both modified: src/ui/login/LoginActivity.kt

# 3. Resolver el conflicto: editar el archivo, eliminar marcadores
# 4. Añadir el archivo resuelto y finalizar el merge
git add src/ui/login/LoginActivity.kt
git merge --continue
# o: git commit (sin --continue)

Existen herramientas para resolver conflictos: git mergetool abre un fusionador visual (Meld, Beyond Compare, VS Code). Muchos desarrolladores prefieren resolver conflictos en el IDE — IntelliJ IDEA y Android Studio proporcionan una herramienta integrada con comparación de tres paneles que simplifica enormemente este proceso.

Consejos para resolver conflictos: comprenda siempre qué hace cada lado del conflicto, no elimine código ajeno sin entender su lógica, y si el conflicto es demasiado complejo — involucre a los autores de ambas ramas en una resolución conjunta.

Merge vs Rebase: cuándo elegir cada uno

La elección entre Merge y Rebase es una de las decisiones arquitectónicas más comunes en Git. Ambos enfoques combinan cambios, pero lo hacen de manera diferente: merge conserva el historial de ramificación, rebase reescribe el historial haciéndolo lineal.

• Merge — conserva el contexto: se puede ver cuándo y desde qué rama se hizo una fusión. Mejor para ramas públicas (develop, main) y trabajo en equipo
• Rebase — crea un historial lineal limpio sin commits de fusión adicionales. Mejor para ramas de funcionalidad personales antes de la revisión
• Regla: nunca hagas rebase de ramas públicas que otros desarrolladores estén usando

Muchos equipos utilizan un enfoque híbrido: rebase para actualizar la rama de funcionalidad con develop (git rebase develop), y luego merge con la bandera --no-ff para registrar la fusión. Esto proporciona un historial limpio dentro de la funcionalidad y puntos de fusión informativos a nivel de develop.