Cómo resolver conflictos de merge en Git sin miedo

Ejecutas git merge y la terminal responde: CONFLICT (content): Merge conflict in src/api.ts. Calma. No es un error. Es Git pidiéndote una decisión que no puede tomar solo.

En esta guía vas a entender por qué ocurre el conflicto, cómo leer lo que Git escribió en el archivo, cómo resolverlo en un merge y en un rebase, qué herramientas ayudan y qué hacer en el día a día para tener menos conflictos.

Por qué ocurre el conflicto

Git une solo los cambios que están en partes distintas de un archivo. Si tú cambiaste la línea 10 y un compañero cambió la línea 80, el merge ocurre sin preguntar nada.

El conflicto aparece en tres situaciones:

Los dos branches cambiaron las mismas líneas, o líneas muy cercanas.
Un lado borró un archivo que el otro editó (deleted by them o deleted by us).
Los dos lados crearon o renombraron el mismo archivo de formas distintas.

En esos casos no existe una respuesta automática correcta. Alguien que conoce el código tiene que revisarlo y decidir.

Cómo leer los marcadores

Dentro del archivo, Git marca el fragmento en disputa así:

<<<<<<< HEAD
const timeout = 30;
=======
const timeout = 60;
>>>>>>> feature/retry

Entre <<<<<<< HEAD y ======= está tu lado, es decir, el branch en el que estás.
Entre ======= y >>>>>>> feature/retry está el lado que llegó con el merge.
Tu tarea es dejar solo el resultado final: un lado, el otro o una combinación de los dos. Y borrar los marcadores.

Un consejo que ayuda mucho: activa el estilo zdiff3. Con él, Git también muestra cómo era el fragmento antes de que los dos lados lo cambiaran, y así queda claro qué quiso hacer cada uno.

git config --global merge.conflictStyle zdiff3

<<<<<<< HEAD
const timeout = 30;
||||||| base
const timeout = 10;
=======
const timeout = 60;
>>>>>>> feature/retry

Ahora puedes ver que el valor original era 10. Tú lo subiste a 30 y tu compañero a 60. La decisión se vuelve mucho más fácil.

Paso a paso para resolver un merge

Ejecuta git status para ver los archivos en conflicto. Aparecen como both modified.
Abre cada archivo, decide cada bloque y quita los marcadores.
Compila y ejecuta las pruebas. Un merge sin marcadores todavía puede romper el código, por ejemplo cuando un lado renombró una función que el otro empezó a usar.
Marca cada archivo como resuelto con git add <archivo>.
Termina con git commit. Git ya sugiere un mensaje de merge.

Si el archivo completo debe quedar como está en uno de los lados, no necesitas editar bloque por bloque:

git checkout --ours src/api.ts     # te quedas con tu lado
git checkout --theirs src/api.ts   # te quedas con el lado que llegó
git add src/api.ts

Si algo se sale de control, git merge --abort regresa todo al estado anterior al merge. Puedes empezar de nuevo con calma.

Conflictos durante un rebase

En el rebase, Git vuelve a aplicar tus commits, uno por uno, encima de otro branch. Por eso el conflicto puede aparecer más de una vez, una por cada commit que toca las mismas líneas.

El flujo es parecido, con una diferencia importante: en el rebase, ours y theirs se invierten. --ours pasa a ser el branch de destino, por ejemplo main, y --theirs es tu commit que se está volviendo a aplicar.

Resuelve los archivos del commit actual y ejecuta git add.
Continúa con git rebase --continue.
Repite hasta que termine el rebase.
Si prefieres desistir, git rebase --abort deja todo como estaba.

Herramientas que ayudan

git mergetool abre una herramienta visual configurada, como VS Code, Meld o KDiff3.
git log --merge -p <archivo> muestra solo los commits de los dos lados que tocaron el archivo en conflicto.
git rerere guarda cómo resolviste un conflicto y vuelve a aplicar la misma solución si aparece de nuevo. Actívalo con git config --global rerere.enabled true.
git diff durante el conflicto muestra solo los fragmentos que aún no están resueltos.

Cómo tener menos conflictos

Trae main a tu branch con frecuencia, no solo al final.
Prefiere branches cortos, que duren días y no semanas.
Haz commits pequeños y enfocados en un solo cambio.
Acuerda un formateador de código con tu equipo, para que los espacios y los saltos de línea no se conviertan en conflictos.
Evita mover un archivo y editar su contenido en el mismo commit.
Habla con tu equipo antes de tocar archivos que todos editan, como rutas, configuraciones y listas de dependencias.

Resolver conflictos en GitMuninn

En GitMuninn, el conflicto aparece bloque por bloque. En cada bloque eliges tu lado, el lado que llegó o los dos, y guardas cuando el archivo está resuelto, sin buscar marcadores. El grafo muestra de dónde vino cada branch, lo que te ayuda a entender el cambio antes de decidir. Esto está incluido en el plan Gratis.