Conflicto de fusión

Un conflicto de fusión ocurre cuando Git está combinando cambios y no puede decidir con seguridad qué versión de un archivo debe ganar.

A pesar del nombre, los conflictos de fusión pueden aparecer durante varias operaciones de Git, no solo al ejecutar git merge. Pueden ocurrir cuando:

• Fusionas una rama en otra con git merge.
• Reaplicas commits encima de otra rama con git rebase.
• Traes cambios remotos con git pull, porque ese comando normalmente ejecuta una fusión o un rebase después de traer información del remoto.
• Aplicas un commit en otro sitio con git cherry-pick.
• Reviertes los cambios de un commit con git revert, si el cambio inverso no se puede aplicar limpiamente.
• Reaplicas cambios guardados en stash con git stash pop o git stash apply.

Los conflictos suelen ocurrir cuando dos ramas han cambiado las mismas líneas de un archivo, o cuando una rama ha cambiado un archivo que otra rama ha eliminado o renombrado. Git detiene la operación para que puedas tomar la decisión final.

Errores relacionados, como "your local changes would be overwritten", no son exactamente lo mismo. En ese caso, Git normalmente se detiene antes de empezar la operación, para que primero puedas guardar o descartar tus cambios locales.

Cuando un archivo de texto tiene un conflicto de contenido, Git escribe marcadores de conflicto dentro del archivo:

<<<<<<< HEAD
la versión de tu rama actual
=======
la versión que Git intenta traer
>>>>>>> feature-branch

La parte que está por encima de ======= es un lado del conflicto. La parte que está por debajo es el otro lado. Tu trabajo consiste en editar el archivo hasta dejar la versión final que realmente quieres y luego eliminar todos los marcadores de conflicto.

Ours y theirs

Git y los editores de código a veces etiquetan los dos lados de un conflicto como ours y theirs. Algunas herramientas usan etiquetas como current e incoming para la misma idea. Ten cuidado con estos nombres: describen los lados de la operación actual de Git, no necesariamente "mi trabajo" y "el trabajo de otra persona".

En una fusión normal, el significado suele ser intuitivo:

git switch main
git merge feature

• Ours es main, la rama en la que estabas antes de empezar la fusión.
• Theirs es feature, la rama que se está fusionando.

Durante un rebase, las etiquetas pueden parecer del revés:

git switch feature
git rebase main

Git coloca temporalmente tu trabajo encima de main. Si aparece un conflicto mientras Git está reproduciendo un commit de feature:

• Ours es el lado de main, porque esa es la base actualmente cargada durante el rebase.
• Theirs es el commit de feature que se está reproduciendo.

Esto significa que elegir ours durante un rebase puede descartar el cambio de la rama que tú consideras "tuya". Comandos como git restore --ours path/to/file y git restore --theirs path/to/file eligen un lado entero de un archivo en conflicto, así que úsalos solo cuando tengas claro qué lado quiere decir Git en la operación actual.

Cómo resolver un conflicto

El flujo habitual es:

1. Ejecuta git status para ver qué archivos tienen conflictos.
2. Abre cada archivo en conflicto y edítalo hasta dejar la versión final correcta.
3. Elimina las líneas de marcadores <<<<<<<, ======= y >>>>>>>.
4. Prepara los archivos resueltos con git add.
5. Continúa la operación: crea el commit de fusión, ejecuta git merge --continue o ejecuta git rebase --continue, según lo que te indique Git.

Si el conflicto apareció por sorpresa y no te viene bien resolverlo ahora, a menudo puedes volver al estado anterior con git merge --abort o git rebase --abort.