Merging combina cambios de una rama en otra — típicamente trayendo una rama de característica completada de vuelta a la rama principal. Git maneja la mayoría de merges automáticamente, pero comprender los tipos de merge y los conflictos es importante.
git switch main # be on the branch you want to merge INTO
git merge feature-x # merge feature-x's changes into main
Cambias a la rama (la que recibe los cambios) y haces merge de la rama en ella.
FAST-FORWARD merge → if main hasn't changed since the branch was created, Git just
MOVES main's pointer forward to the branch's latest commit (no merge commit, linear)
MERGE COMMIT (three-way merge) → if BOTH branches have new commits, Git creates a new
"merge commit" combining them (has two parents) → preserves that a merge happened
→ git merge --no-ff forces a merge commit even when fast-forward is possible
Git hace fast-forward cuando es posible (simplemente avanzando el puntero) o crea un merge commit (con dos padres) cuando ambas ramas divergieron.
A CONFLICT happens when both branches changed the SAME lines differently — Git can't
auto-decide which to keep, so it asks YOU to resolve:
<<<<<<< HEAD
the version from the current branch (main)
=======
the version from the branch being merged (feature-x)
>>>>>>> feature-x
# resolve: edit the file to the desired result, remove the markers, then:
git add <file> # mark the conflict resolved
git commit # complete the merge
# git merge --abort # or cancel the merge entirely
Los conflictos ocurren cuando ambas ramas cambian las mismas líneas — Git los marca y tú eliges manualmente el resultado correcto, luego haces stage y commit.
Comprender merging es esencial porque combinar cambios de ramas es una parte fundamental y constante de los flujos de trabajo colaborativos en Git, así que saber cómo funciona (incluyendo conflictos) es conocimiento necesario de todos los días. Merging es cómo el trabajo completado (típicamente ramas de característica) se integra de vuelta en la rama principal — el acto rutinario de traer cambios juntos que ocurre continuamente en desarrollo en equipo.
Comprender la diferencia entre un fast-forward merge (Git simplemente avanzando el puntero cuando el objetivo no ha divergido, manteniendo el historial lineal) y un merge commit (un merge de tres vías creando un nuevo commit con dos padres cuando ambas ramas tienen nuevos commits, registrando que un merge ocurrió) aclara cómo Git integra cambios y cómo se ve el historial resultante.
Lo más importante, comprender conflictos de merge — que ocurren cuando ambas ramas cambian las mismas líneas de manera diferente, así que Git no puede decidir automáticamente y te pide que resuelvas — es conocimiento práctico crucial: los conflictos son una parte normal e inevitable de la colaboración, y saber cómo reconocer los marcadores de conflicto (<<<<<<<, =======, >>>>>>>), editar el archivo al resultado correcto, y completar el merge (hacer stage y commit) es una habilidad esencial que frecuentemente es una fuente de ansiedad para quienes no lo comprenden.
Ya que integrar cambios de ramas a través de merging es fundamental y constante en desarrollo colaborativo, y ya que comprender tipos de merge y especialmente resolver conflictos es necesario para combinar trabajo correctamente (una tarea rutinaria e inevitable), entender cómo funciona merging — merges básicos, fast-forward vs merge commits, y resolución de conflictos — es conocimiento esencial de Git frecuentemente aplicado, una habilidad central para colaboración donde la resolución de conflictos en particular es una necesidad práctica que todo desarrollador debe manejar con confianza.