Cómo resolver conflictos de merge en Git y GitHub

Es el mensaje que imprime git merge cuando intenta combinar dos ramas y encuentra que ambas modificaron la misma parte de un mismo archivo con contenido distinto, así que no puede fusionarlas de forma automática. La palabra content especifica el tipo de conflicto: se refiere a un choque dentro del contenido del archivo, a diferencia de otros tipos de conflicto que Git también reporta, como cuando una rama borra un archivo y la otra lo modifica. Después de ese mensaje, Git no aborta el proceso completo: detiene únicamente la fusión de ese archivo puntual y sigue con los demás si los hay, así que un merge con varios archivos puede terminar con algunos ya combinados sin problema y otros marcados como conflicto. Por eso conviene correr git status inmediatamente después de ver el mensaje: ahí aparece la lista completa de archivos con conflicto bajo la sección Unmerged paths, con el estado both modified para los que, como en este caso, fueron modificados por las dos ramas. El mensaje no indica ningún error de tu parte ni un problema en el repositorio: es exactamente el comportamiento esperado de Git cuando dos historias de cambios se superponen en el mismo lugar, y la fusión queda en pausa hasta que resolvés manualmente ese archivo, lo marcás con git add y confirmás con un commit.

Los marcadores que Git deja en el archivo siguen siempre el mismo orden, sin importar qué dos ramas estés fusionando. Todo lo que aparece entre la línea <<<<<<< HEAD y la línea ======= es la versión que ya tenía tu rama actual, es decir, la rama en la que estabas parado cuando ejecutaste git merge; HEAD es, en este contexto, un apodo para «donde estás vos ahora». Todo lo que aparece entre la línea ======= y la línea >>>>>>> nombre-rama es la versión que trae la rama que estás intentando fusionar, y Git escribe el nombre real de esa rama al lado de la marca de cierre para que sepas de dónde vino. Esta convención no cambia según la dirección del merge: si fusionás la rama B dentro de la rama A, el bloque de arriba (HEAD) siempre va a ser el contenido de A, y el de abajo, el de B, porque HEAD apunta a la rama donde estás parado, no a un lado fijo del conflicto. Tu tarea como persona es leer ambos bloques, decidir qué contenido final tiene sentido —puede ser uno de los dos, una combinación de ambos, o algo distinto a los dos— y dejar ese contenido en el archivo, borrando las tres líneas de marcadores, que no son código válido y romperían el archivo si quedaran ahí.

Con git merge --abort, pero hay una condición temporal que conviene tener clara: ese comando solo funciona mientras el merge sigue en curso, es decir, mientras todavía no confirmaste la resolución con un commit. Ejecutarlo en ese momento deshace por completo el intento de fusión y devuelve tu rama exactamente al estado en el que estaba antes de correr git merge, como si nunca lo hubieras intentado; los cambios de la otra rama vuelven a quedar afuera, y podés retomarlo más tarde con calma. El problema aparece si ya resolviste los conflictos, hiciste git add y confirmaste con git commit (o con git merge --continue, que hace lo mismo): en ese punto el merge ya terminó, ya no hay nada «en curso» que abortar, y git merge --abort directamente no tiene efecto porque no hay ningún proceso de fusión pendiente al que aplicarse. Si te arrepentís después de ese commit, las herramientas cambian: si el commit todavía es local y no lo compartiste con nadie, git reset te permite mover tu rama a un punto anterior, aunque reescribe el historial local. Si ya lo subiste y otras personas pueden tener ese historial, la opción más segura es git revert, que no borra el commit de fusión sino que crea uno nuevo que anula sus cambios, preservando el historial tal como quedó. La clave para no llegar tarde es recordar: --abort sirve antes de confirmar, no después.

Ese patrón es exactamente el que resuelve git rerere, que significa reuse recorded resolution (reutilizar una resolución grabada). Se activa con git config rerere.enabled true (o --global para que valga en todos tus repositorios), y a partir de ahí Git empieza a grabar cómo resolviste cada conflicto: guarda el estado del archivo con los marcadores tal como quedaron y el contenido final que dejaste después de resolverlo. La próxima vez que aparezca un conflicto con esa misma forma —algo muy habitual durante un rebase, porque un rebase reaplica cada commit uno por uno y puede chocar contra el mismo cambio en cada paso—, Git reconoce el patrón grabado y aplica automáticamente la misma resolución, sin que tengas que repetir el trabajo manual en cada commit del rebase. Es una herramienta que rinde muchísimo en rebases largos o que se repiten, porque evita resolver diez veces un conflicto que en el fondo es siempre el mismo. Tiene una limitación documentada que conviene conocer: rerere reconoce el conflicto por cómo quedan los marcadores en el archivo, así que si el conflicto cambia levemente de forma —otras líneas alrededor, un contexto distinto— puede no reconocerlo como el mismo caso y no aplicar nada, o aplicar una resolución que ya no es la correcta para ese contexto nuevo. Por eso conviene revisar igual el resultado antes de confirmar, en lugar de confiar en rerere a ciegas.

Sí, es el mismo mecanismo de fusión de Git por debajo; lo único que cambia es la interfaz desde la que lo operás. Cuando una solicitud de cambios (pull request) en GitHub no se puede fusionar de forma automática porque hay conflictos, GitHub lo muestra con un aviso en la propia página de la solicitud, y para conflictos simples ofrece un editor web donde ves los mismos bloques delimitados por marcadores que verías en tu terminal, elegís qué contenido final dejar, y GitHub genera un commit de resolución sobre tu rama, igual que hubiera quedado si lo resolvías vos localmente y subías el resultado con push. La diferencia práctica es de alcance: el editor de conflictos de GitHub está pensado para casos acotados, con pocos archivos y cambios sencillos de decidir mirando el texto; si el conflicto es más complejo, involucra varios archivos, o preferís usar tu propio editor o una herramienta de fusión visual, la vía recomendada sigue siendo traer la rama a tu máquina, correr git merge o git pull en tu terminal, resolver ahí con las mismas herramientas de siempre (incluido git mergetool si lo tenés configurado) y subir el resultado con push, lo que actualiza automáticamente la solicitud de cambios en GitHub. En ningún caso GitHub inventa una forma distinta de fusionar: usa Git como motor, y la web es una capa de comodidad para resolver sin salir del navegador cuando el caso lo permite.

Git no impone ninguna herramienta: el comando git mergetool abre la que tengas configurada en tu entorno, y sirve para no tener que leer los marcadores como texto plano y decidir a ojo. En lugar de eso, una herramienta de fusión visual te muestra habitualmente tres paneles —tu versión, la versión de la rama entrante y, en algunos casos, el ancestro común de las dos— y te deja elegir bloque por bloque cuál contenido final aplicar, o editar directamente un panel con el resultado, sin la sobrecarga de leer <<<<<<<, ======= y >>>>>>> a mano en cada conflicto. Muchos editores de código modernos, incluido Visual Studio Code, incorporan su propio editor de fusión de varios paneles y pueden configurarse como la herramienta que usa git mergetool, de modo que resolver un conflicto se sienta parte del mismo flujo de edición que ya usás para programar, en lugar de una tarea aparte. Sea cual sea la herramienta elegida, el mecanismo de fondo no cambia: al terminar, hay que marcar el archivo como resuelto con git add y confirmar con un commit, igual que si lo hubieras editado en un bloc de notas. La herramienta visual ahorra errores de lectura y hace más cómoda la decisión, pero no la reemplaza: elegir qué contenido final tiene sentido sigue siendo trabajo humano.