Cómo resolver un conflicto de merge en Git paso a paso

🎧 Escuchar esta guía

Paso 1: comprueba qué archivos tienen conflictos

git status
# "Unmerged paths:" enumera los archivos con conflictos:
#   both modified:   config.py

Paso 2: abre el archivo y lee los marcadores

<<<<<<< HEAD
timeout = 30                 # ← TU versión (rama actual)
=======
timeout = 60                 # ← SU versión (rama entrante)
>>>>>>> feature-x

# todo lo que queda entre los marcadores está en disputa.
# el resto del archivo ya se ha fusionado correctamente.

Paso 3: deja el resultado correcto y borra los tres marcadores

# conserva tu versión, la suya o escribe una nueva:
timeout = 60

# al terminar deben cumplirse dos cosas:
# 1. el código hace exactamente lo que quieres
# 2. no queda ningún <<<<<<<, ======= o >>>>>>> en el archivo

Paso 4: márcalo como resuelto y termina el merge

git add config.py
git commit                   # git prepara el mensaje de merge: guarda y cierra
# listo. el commit de merge une ambos historiales.

Atajo: quédate con un lado entero

# todo el archivo, mi versión:
git checkout --ours  config.py  && git add config.py
# todo el archivo, su versión:
git checkout --theirs config.py && git add config.py

# va muy bien con archivos de bloqueo (package-lock.json, etc.).
# a menudo conviene elegir un lado y volver a ejecutar la instalación.

Los dos errores clásicos
1. Confirmar los marcadores. La aplicación se cae y señala una línea con <<<<<<<. Busca <<<<<<< en todo el proyecto antes de confirmar un merge. 2. Resolver con prisas eligiendo un lado a ciegas. Los marcadores muestran qué cambió, pero no por qué. Si ambos cambios parecen intencionados, pregunta a la otra persona. Dos minutos de conversación salen mucho más baratos que romper de nuevo su arreglo.

¿Te ha ocurrido durante un rebase?
Los marcadores y la edición son iguales, pero se termina con git rebase --continue, no con commit. La salida de emergencia es git rebase --abort. Durante un rebase, «ours» y «theirs» están intercambiados: lee las etiquetas de los marcadores y no te fíes de la intuición.

Cómo tener menos conflictos (la solución de verdad)

git pull often               # los merges pequeños y frecuentes ganan a los grandes y escasos
# procura que las ramas duren poco: días, no meses
# no reformatees archivos enteros en el mismo commit que cambia la lógica
#   (los diffs de formato son fábricas de conflictos)

📚 Esta página forma parte de nuestra serie sobre Git. El modelo mental completo —los tres árboles y las ramas como post-its—, con audio: Git en 10 minutos →

Cómo resolver un conflicto de merge en Git