Un recorrido del tutorial Resolver conflictos de fusión: por qué fusionar el cambio de Alice choca con el tuyo, cómo leer los marcadores de conflicto y cómo terminar la fusión.
Este escenario te pone en una situación de equipo muy común: tú y un compañero habéis cambiado la misma línea, y Git necesita ayuda para combinar las dos. Vas a traer el trabajo de tu compañera, fusionarlo en tu rama, resolver el choque a mano y completar la fusión.
La situación
Git fusiona por sí solo las ediciones a líneas distintas; la misma línea cambiada en ambos lados es un conflicto.
Estás en la rama feature/update-subtitle, donde reescribiste el subtítulo del hero en index.html. Mientras tanto, tu compañera Alice subió su propia edición de esa misma línea de subtítulo a main.
Dos ediciones distintas de la misma línea, en dos ramas. Git puede hacer fast-forward o autofusionar cambios que tocan sitios distintos, pero cuando ambos lados cambian la misma línea no puede adivinar cuál gana. Eso es un conflicto de fusión, y solo tú puedes decidir el resultado.
Un conflicto no es un error de tu parte. Es Git pausándose para que un humano elija, porque ambas ediciones son válidas por sí mismas.
Recorrerlo paso a paso
Resolver un conflicto: edita el archivo, prepáralo y luego commitea.
Poner main al día
git checkout main
git pull
Cambiar a main y hacer pull trae el cambio de subtítulo de Alice desde el remoto, así que tu main local ya tiene su trabajo.
Fusionar main en tu rama de feature
git checkout feature/update-subtitle
git merge main
Git intenta combinar la línea de subtítulo de Alice con la tuya, falla en esa línea y reporta un conflicto en index.html. La fusión se pausa aquí.
Abrir el archivo y leer los marcadores
La región en conflicto se ve así:
<<<<<<< HEAD
tu versión del subtítulo
=======
la versión de Alice del subtítulo
>>>>>>> main
HEAD es tu rama; la parte tras ======= es el cambio entrante desde main.
Resolver y terminar la fusión
git add index.html
git commit
Edita index.html para que contenga el único subtítulo final que quieres y borra las líneas <<<<<<<, ======= y >>>>>>>. Preparar el archivo le dice a Git que el conflicto está zanjado, y el commit registra la fusión.
Leer los marcadores de conflicto
Los tres marcadores y los dos lados que envuelven.
Los tres marcadores aparecen siempre en el mismo orden:
<<<<<<< HEAD a ======= es tu lado.
======= a >>>>>>> es el lado entrante.
- Resolver significa dejar el contenido que quieres y quitar las tres líneas de marcadores.
git status durante un conflicto lista los archivos pendientes de resolver bajo "Unmerged paths". Cuando esa lista está vacía, puedes commitear.
No dejes ninguna línea de marcador en el archivo. Un ======= olvidado se commiteará como contenido real y romperá la página. Busca los marcadores en el archivo antes de prepararlo.
Si quieres volver a empezar
Si una resolución se complica, puedes abortar toda la fusión y volver al estado anterior:
git merge --abort
Comandos de conflictos de fusión que realmente usarás
Más allá de este escenario, estos son los comandos que aparecen cada vez que te topas con un conflicto:
- Ver qué archivos están en conflicto —
git status, o git diff --name-only --diff-filter=U para obtener solo la lista
- Abrir el conflicto — edita el archivo y elimina los marcadores
<<<<<<<, =======, >>>>>>>, dejando la redacción final
- Quedarte con un lado del archivo por completo —
git checkout --ours <archivo> (tu rama) o git checkout --theirs <archivo> (la rama entrante), y luego git add <archivo>
- Terminar la fusión — prepara los archivos resueltos con
git add, y luego git commit (o git merge --continue)
- Rendirte y volver atrás —
git merge --abort restaura el estado anterior a la fusión
La forma más rápida de coger soltura es provocar un conflicto a propósito en la terminal de aquí y resolverlo de varias maneras distintas: a mano, con --ours y con --theirs.