Cómo Resolver Conflictos de Merge en Git Paso a Paso
Guía práctica para entender las marcas de conflicto (`<<<<<<<`, `=======`, `>>>>>>>`), resolver discrepancias en VS Code y terminal, y completar el merge con éxito sin perder código.
Un conflicto de fusión (merge conflict) ocurre en Git cuando dos ramas han modificado exactamente las mismas líneas dentro del mismo archivo o cuando una rama borró un archivo que la otra rama modificó, impidiendo que Git decida automáticamente qué versión conservar.
Lejos de ser un fallo o un error del sistema, los conflictos son la garantía de seguridad de Git para proteger tu código contra sobreescrituras accidentales silenciosas; aprender a resolverlos con serenidad es la prueba de madurez técnica de todo desarrollador.
Imagina que tú y un compañero están corrigiendo el mismo párrafo de un contrato físico en hojas separadas: tú tachaste la última frase y escribiste 'Plazo de 30 días', mientras que tu compañero escribió 'Plazo de 60 días'. Ninguna máquina puede adivinar cuál es la fecha real acordada; ambos deben sentarse, comparar las dos opciones y decidir juntos cuál queda en el documento final.
Explicación Paso a Paso del Tema
Identificar los archivos en estado de conflicto
Usa `git status` para ver qué archivos requieren tu intervención manual.
Cuando Git se detiene con el mensaje 'Automatic merge failed', ejecuta `git status`. Los archivos con problemas aparecerán bajo la sección 'Unmerged paths' marcados como 'both modified' (modificado por ambos).
git status
| Parámetro / Flag | Tipo / Rol | Significado y Uso |
|---|---|---|
| both modified | Estado de archivo | Indica que ambas ramas alteraron las mismas líneas en ese documento |
Si necesitas respirar o consultar con tu compañero qué código conservar antes de tocar nada, puedes correr `git merge --abort` para dejar todo tal como estaba.
Entrar en pánico y borrar carpetas enteras o cerrar el editor pensando que el repositorio se corrompió. Git simplemente pausó el proceso para pedir tu decisión humana.
Leer y editar las marcas de conflicto
Abre el archivo en conflicto y analiza los tres delimitadores de Git.
Git inserta texto explícito en el archivo: `<<<<<<< HEAD` (marca lo que tú tienes), seguido de `=======` (la línea divisoria), luego el código que viene de la otra rama, y finaliza con `>>>>>>> nombre-de-rama`. Tu trabajo consiste en borrar los marcadores y dejar únicamente el código final deseado (que puede ser una de las opciones o una combinación de ambas).
<<<<<<< HEAD const puerto = 3000; ======= const puerto = 8080; >>>>>>> feature/servidor
| Parámetro / Flag | Tipo / Rol | Significado y Uso |
|---|---|---|
| <<<<<<< HEAD | Delimitador superior | Marca el inicio del bloque de tu rama activa actual |
| ======= | Línea de separación | Divide las dos versiones en disputa |
| >>>>>>> [rama] | Delimitador inferior | Marca el fin del bloque proveniente de la rama externa |
En VS Code, aparecen botones sobre el conflicto: 'Accept Current Change', 'Accept Incoming Change' o 'Accept Both Changes' para resolverlo con un solo clic.
Dejar accidentalmente líneas con `<<<<<<<` o `=======` en el archivo y guardarlo. Esto generará un error de sintaxis que romperá la compilación de tu software.
Confirmar la solución del conflicto
Agrega el archivo corregido a Staging y completa el commit de fusión.
Una vez que eliminaste las marcas y probaste que el código compila y funciona: 1. Ejecuta `git add <archivo-resuelto>` para indicarle a Git que el conflicto ha sido resuelto. 2. Ejecuta `git commit` (sin `-m` para que use el mensaje automático predeterminado de merge o con tu mensaje descriptivo). Con esto, la fusión queda exitosamente finalizada.
git add config.js && git commit -m "merge: resolver conflicto de puerto entre main y feature"
| Parámetro / Flag | Tipo / Rol | Significado y Uso |
|---|---|---|
| git add config.js | Marca de resolución | Comunica a Git que el archivo en disputa ya fue verificado y validado por un humano |
| git commit | Cierre de fusión | Crea el commit de fusión definitivo (merge commit) cerrando el proceso |
Para prevenir conflictos grandes en equipos colaborativos, fomenta ramas cortas de no más de dos días de vida y haz `git pull` de la rama principal frecuentemente.
Ejecutar `git commit` sin haber hecho antes `git add` de los archivos en conflicto resueltos.
Casos Prácticos Reales en Producción
Situaciones de ingeniería reales sin mención de presupuestos ficticios.
1Caso de Producción: Resolución de Conflicto en Configuración de Base de Datos
Dos ingenieros modificaron el archivo de variables de conexión de la base de datos al mismo tiempo: uno añadió el parámetro de reconexión automática y el otro aumentó el pool de conexiones a 50.
Al intentar fusionar a `main`, Git detectó conflicto en el bloque de opciones. En lugar de descartar uno en favor del otro, el líder técnico editó el archivo integrando ambas propiedades juntas (`autoReconnect: true` y `maxPoolSize: 50`), borró las marcas de Git y confirmó el merge.
Fichas Nemotécnicas de Conceptos Clave
Glosario rápido para recordar los términos fundamentales de la lección.
Marcador que delimita el inicio del código tal como existía en la rama donde estás actualmente posicionado.
Marcador que delimita el final del bloque de código proveniente de la rama que estás intentando fusionar.
Comando salvavidas que cancela de inmediato la fusión en curso y devuelve el repositorio al estado exacto previo al intento de merge.
Cómo Resolver Conflictos de Merge en Git Paso a Paso
Selecciona una opción para autoevaluarte al instante. La respuesta se califica de inmediato.
¿Qué comando cancela de forma inmediata un proceso de fusión en conflicto y restaura el estado original previo?
¿Qué representa la sección delimitada entre '<<<<<<< HEAD' y '======='?
¿Qué paso es obligatorio realizar después de limpiar las marcas de conflicto en el archivo para que Git sepa que está solucionado?
Preguntas Frecuentes (FAQ)
¿Por qué Git no puede elegir automáticamente la versión más reciente?
Porque la fecha de modificación no indica corrección lógica. Podrías haber borrado una función de seguridad vital en el último minuto; si Git asumiera esa opción a ciegas, causaría brechas de seguridad catastróficas.
¿Puedo deshacer un conflicto si me equivoqué a la mitad de resolverlo?
Sí. Mientras no hayas terminado el commit, ejecuta `git merge --abort` y el proyecto volverá de inmediato al estado previo al inicio del merge.
¿Cómo puedo evitar que se produzcan tantos conflictos en mi equipo?
Divide las tareas en módulos y archivos independientes, mantén tus ramas pequeñas y actualízalas continuamente haciendo merge o rebase de la rama principal a diario.