Hasta ahora hemos tenido suerte. Todas las fusiones del módulo han salido bien porque Ana y Bruno tocaban zonas distintas de los ficheros. Se acabó la suerte: en esta lección los dos van a modificar las mismas líneas de la misma función, cada uno por un motivo perfectamente razonable, y Git se va a detener a mitad de la fusión.

Los conflictos de fusión tienen mala fama, y es inmerecida. Un conflicto no es un error, no es una corrupción y no significa que hayas hecho nada mal. Es Git diciéndote, con toda la honestidad del mundo: "aquí hay dos cambios incompatibles sobre las mismas líneas y no tengo criterio para elegir; decide tú". La alternativa —que un algoritmo decidiera por su cuenta qué código de qué persona sobrevive— sería mucho peor.

Lo que sí genera angustia es la sensación de estar atrapado: el repositorio en un estado raro, unos símbolos extraños dentro del código y la duda de si acabas de romper algo. Esta lección elimina esa angustia. Al terminarla sabrás exactamente en qué estado está tu repositorio durante un conflicto, cómo leer lo que Git ha escrito en el fichero, cómo resolverlo y, si te agobias, cómo dar marcha atrás sin dejar rastro.

1. Por qué se produce un conflicto
2. Provocando un conflicto de verdad
3. Los marcadores de conflicto
4. El estilo diff3 y zdiff3: ver también el ancestro
5. Orientarse durante el conflicto: git status
6. git diff durante un conflicto: las tres versiones
7. Resolver y marcar como resuelto
8. Atajos: --ours y --theirs por fichero
9. Abortar: --abort y --quit
10. git mergetool: herramientas gráficas
11. Conflictos especiales: borrado frente a modificado
12. git rerere: no resolver dos veces lo mismo

Recuerda la tabla de decisión de la fusión a tres bandas de la lección 03-03. Para cada trozo de fichero, Git compara tres versiones: la del ancestro común (base), la de tu rama (ours) y la de la rama que fusionas (theirs).

Solo la última fila produce conflicto: las dos ramas cambiaron lo mismo de forma distinta.

Y hay que precisar qué significa "lo mismo", porque es la fuente de un miedo muy extendido:

• Que dos personas toquen el mismo fichero NO produce conflicto. Si Ana edita la línea 10 y Bruno la 200, Git combina las dos sin decir nada.
• Produce conflicto que toquen las mismas líneas, o líneas tan próximas que caen en el mismo trozo (hunk) del diff. Git trabaja con un margen de contexto de tres líneas, así que cambios separados por una o dos líneas también pueden chocar.

Además de los conflictos de contenido, existen los conflictos de árbol (tree conflicts), que afectan a la existencia o ubicación del fichero en lugar de a su interior:

Los de contenido son el 90 % de los casos y son lo que veremos primero. El de borrado/modificado, por ser el segundo más frecuente, tiene su apartado.

Volvamos al proyecto. main está al día con todo lo integrado en las lecciones anteriores, y app.js contiene esta función, que pinta el listado de tareas en pantalla:

Ana abre una rama para mostrar las tareas ordenadas alfabéticamente:

Y modifica la función:

Bruno, mientras tanto, abre otra rama desde el mismo punto para arreglar algo que le han reportado: cuando no hay tareas, la pantalla queda en blanco y parece que la aplicación está rota.

Los dos cambios son buenos y el proyecto los quiere los dos. Pero ambos insertan código justo en el mismo punto: entre lista.innerHTML = ''; y el forEach. Git no tiene forma de saber si el if de Bruno va antes o después del sort de Ana, ni si el forEach debe recorrer tareas u ordenadas.

Ana integra primero lo suyo, que va limpio:

Y ahora, el de Bruno:

Ahí está. Vamos a diseccionarlo.

Lo primero que hay que entender: Git ha modificado tu fichero en disco. app.js ya no contiene código válido de JavaScript, sino código con anotaciones dentro:

Los marcadores por defecto son tres:

Observaciones importantes que se pasan por alto:

1. Solo la zona conflictiva lleva marcadores. Las tres primeras líneas de la función y las tres últimas están limpias: Git las fusionó sin problema. Un fichero de 400 líneas con un conflicto de 6 tiene 394 líneas ya resueltas.

2. Un fichero puede tener varios bloques de conflicto, cada uno con su juego de marcadores. Hay que resolverlos todos.

3. Los marcadores son texto normal. No hay nada mágico en ellos: puedes editarlos, borrarlos o dejarlos (si los dejas, git commit te avisará, pero puedes forzarlo y meter basura en el proyecto, así que revisa siempre).

4. La etiqueta de la derecha es el nombre de la rama fusionada, lo que ayuda mucho cuando estás fusionando varias cosas seguidas y te has perdido.

Y aquí está el problema del formato por defecto: no ves lo que había antes. ¿El forEach sobre tareas de la versión de Bruno es un cambio suyo o simplemente el código original que él no tocó? Con este formato no puedes saberlo, y esa información es exactamente la que necesitas para resolver bien. Para eso está el apartado siguiente.

Git puede mostrar tres secciones en lugar de dos, añadiendo la del ancestro común. Se controla con la opción merge.conflictStyle:

Abortamos y repetimos la fusión para verlo:

Ahora app.js contiene:

El bloque nuevo, delimitado por ||||||| y etiquetado con el hash del ancestro común, contiene el código original. Y ahora la lectura es completamente distinta:

• El ancestro tenía tareas.forEach(...).
• Ana lo cambió por el bloque sort + ordenadas.forEach(...).
• Bruno añadió el if delante y no tocó el forEach.

Con esa información, la resolución es evidente: hay que quedarse con las dos cosas, poniendo el if de Bruno primero y respetando el cambio de tareas a ordenadas de Ana.

Sin el ancestro, habrías tenido que deducirlo o consultar el historial. Con él, se ve de un vistazo.

Desde Git 2.35 existe un estilo más: zdiff3 (por zealous diff3). Hace lo mismo que diff3 pero además saca fuera del conflicto las líneas comunes a los dos lados:

En conflictos donde los dos lados comparten líneas al principio o al final del bloque, la zona conflictiva se reduce notablemente y solo queda dentro lo que de verdad discrepa.

Este es probablemente el consejo más rentable de toda la lección. Ponlo ahora mismo:

git config --global merge.conflictStyle zdiff3

Encaja con lo que ya configuraste en la lección 01-06 y no tiene ninguna contrapartida.

Durante un conflicto, el repositorio está en un estado especial. git status es tu brújula y cambia por completo:

Elementos clave:

• You have unmerged paths: hay una fusión a medias.
• Unmerged paths: sección nueva, distinta de "preparados" y "sin preparar". Aquí van los ficheros en conflicto.
• both modified: el tipo de conflicto. Otros posibles: deleted by us, deleted by them, both added, added by us.
• Git te recuerda las dos salidas: resolver y confirmar, o abortar.

En formato corto:

UU significa unmerged en las dos columnas. La tabla completa de códigos de conflicto:

Si solo quieres la lista de ficheros pendientes, sin ruido:

Es el comando que se usa en scripts y en atajos de editor para saltar de un conflicto a otro.

Merece la pena mirarlo una vez, porque desmitifica el estado:

MERGE_HEAD guarda el commit que estás fusionando. Su existencia es lo que define "estar en una fusión": es por lo que git commit sabe que debe crear un commit con dos padres, y por lo que git merge --abort sabe qué deshacer. MERGE_MSG guarda el mensaje propuesto.

Y el índice (el área de preparación) también es especial ahora. Normalmente guarda una versión de cada fichero; durante un conflicto guarda tres, numeradas por etapas:

Esas tres etapas son lo que hace posible todo lo que viene a continuación: los diffs especiales, --ours/--theirs y las herramientas gráficas. Cuando resuelves y haces git add, las tres etapas se sustituyen por una única versión normal, y así es como Git sabe que ese fichero ya está resuelto.

git diff a secas, durante un conflicto, muestra un formato que no habías visto: el diff combinado.

Fíjate en que hay dos columnas de marcadores +/- en lugar de una, y en la cabecera @@@ con tres arrobas. Cada columna corresponde a un padre. Es un formato denso; en la práctica se usan más los diffs por parejas.

Para comparar el fichero en conflicto con cada una de las tres versiones:

También puedes recuperar cualquiera de las tres versiones completas para verlas de forma aislada, con la sintaxis :<etapa>:<ruta>:

Esto es enormemente útil cuando el conflicto es grande y quieres leer cada versión entera sin marcadores, en lugar de intentar descifrar el fichero mezclado. Por ejemplo, para guardar la versión de Bruno en un fichero aparte y consultarla mientras editas:

Resolver un conflicto es, simplemente, dejar el fichero como debe quedar. Ni más ni menos. No hay ningún comando mágico: se edita el fichero, se quitan los marcadores y se escribe el código correcto.

En nuestro caso, sabemos por el bloque ||||||| que hay que combinar las dos aportaciones. Ana edita app.js y lo deja así:

Sin marcadores. El if de Bruno va primero (si no hay tareas, no tiene sentido ordenarlas) y después el sort de Ana. Es código que no existía en ninguna de las dos ramas: es la síntesis que solo una persona podía hacer. Eso es exactamente lo que Git te estaba pidiendo.

Antes de dar nada por bueno, hay que probarlo. Un conflicto resuelto sin ejecutar el código es una apuesta:

Y a continuación, abrir la aplicación o pasar las pruebas.

Ahora se marca como resuelto:

git add sobre un fichero en conflicto tiene un significado especial: sustituye las tres etapas del índice por la versión del disco y declara el conflicto resuelto. No es "preparar un cambio"; es "he decidido, esta es la versión buena".

All conflicts fixed but you are still merging: la fusión sigue en curso (MERGE_HEAD existe todavía), pero ya no hay nada bloqueado. Solo falta confirmar:

Git abre el editor con el mensaje que guardó en MERGE_MSG, ahora con una anotación adicional:

Es una excelente costumbre describir cómo se resolvió, porque quien lea esto dentro de un año lo agradecerá:

Y aquí es donde --cc, que vimos en la lección 03-03, cobra todo su sentido:

Muestra solo las líneas que difieren de los dos padres, es decir, exactamente el código que Ana escribió a mano al resolver. Es la forma de auditar una resolución de conflicto sin leer todo el fichero.

A veces no hay nada que sintetizar: una de las dos versiones es la correcta y punto. Típico en ficheros generados automáticamente, ficheros de bloqueo de dependencias o cuando sabes que el trabajo de un lado dejó obsoleto el del otro.

O con los comandos modernos que vimos en la lección 03-02:

Estos comandos sobrescriben el fichero del disco con la etapa 2 o la 3 del índice, marcadores incluidos fuera. Después hay que marcarlo como resuelto igualmente:

Dos avisos importantes:

1. Cogen el fichero ENTERO, no solo la zona conflictiva. Si app.js tenía además cambios de la otra rama en otra parte del fichero que se habían fusionado bien, --ours los tira también. Úsalo solo cuando de verdad quieras una versión completa.

2. No los confundas con -X ours/-X theirs de la lección anterior. Estos actúan fichero a fichero, durante un conflicto ya producido; aquellos actúan globalmente, antes de que el conflicto aparezca.

Un patrón muy práctico cuando hay varios ficheros y solo algunos son "automáticos":

Y si prefieres empezar de cero un fichero que has estropeado editando:

Restaura el fichero con los marcadores de conflicto originales, como estaba justo después de la fusión fallida.

Si te has perdido, si el conflicto es mucho mayor de lo que esperabas o si simplemente prefieres hacerlo en otro momento, se sale sin dejar rastro:

Como si la fusión no hubiera existido. git merge --abort deshace todo: restaura el directorio de trabajo y el índice al estado anterior a git merge, y borra MERGE_HEAD y MERGE_MSG.

Es la operación más tranquilizadora de Git y conviene interiorizarla: durante un conflicto nunca estás atrapado. Siempre hay una tecla de escape.

Una precaución: si tenías cambios sin confirmar antes de empezar la fusión, --abort puede no ser capaz de recuperar el estado exacto. Por eso la recomendación de la lección 03-03 —fusionar con el directorio limpio— no es una manía.

Existe también un primo raro:

--quit sale del estado de fusión (borra MERGE_HEAD) pero deja el directorio de trabajo y el índice tal como están, con los marcadores y todo. Es para casos muy concretos: quieres conservar el resultado a medias pero no quieres que Git cree un commit de fusión con dos padres. Si no sabes que lo necesitas, no lo necesitas: usa --abort.

Para conflictos grandes, editar marcadores a mano es incómodo. git mergetool abre una herramienta de tres o cuatro paneles: base, ours, theirs y resultado.

Si no has configurado ninguna, Git elige la primera que encuentre instalada. Para fijar una:

Y una opción que casi todo el mundo acaba activando:

Sin ella, git mergetool deja ficheros *.orig con la versión conflictiva por todas partes, y luego hay que borrarlos a mano (o ignorarlos en .gitignore).

Las cuatro variables que la herramienta recibe, y que conviene entender para configurar la tuya:

Al guardar y salir de la herramienta, git mergetool marca el fichero como resuelto automáticamente (hace el git add por ti) y pasa al siguiente conflicto si lo hay.

Un apunte práctico: hoy la mayoría de editores modernos incluyen su propio resolvedor de conflictos que detecta los marcadores en el fichero y ofrece botones tipo "aceptar el actual / aceptar el entrante / aceptar los dos". Funcionan sobre el mismo fichero con marcadores que hemos visto, así que todo lo aprendido aquí se aplica igual. git mergetool sigue siendo útil cuando quieres los cuatro paneles con el ancestro a la vista.

El segundo tipo de conflicto más frecuente no ocurre dentro del fichero, sino sobre su existencia.

Situación: el proyecto tenía un fichero notas-internas.md con apuntes del principio del desarrollo. Ana decidió que estaba obsoleto y lo borró en su rama:

Bruno, que no lo sabía, lo actualizó en la suya:

Ana fusiona lo suyo en main (sin problema) y luego lo de Bruno:

Fíjate en dos cosas:

1. El tipo de conflicto es modify/delete, no content.
2. No hay marcadores dentro del fichero. No tendría sentido: el conflicto no es sobre su contenido, sino sobre si debe existir. Git ha dejado en el disco la versión de Bruno, como dice el mensaje.

deleted by us: nosotros (la rama en la que estamos) lo borramos, ellos lo modificaron. Git no puede decidir si el borrado era correcto o si las actualizaciones de Bruno lo justifican; eso depende de por qué se borró, y eso solo lo sabe una persona.

La resolución consiste en declarar qué debe pasar, y solo hay dos opciones:

En los dos casos, después:

Antes de decidir, conviene mirar qué contenían esos cambios, no vaya a ser que Bruno hubiera escrito algo que merece conservarse en otro sitio:

Y si la respuesta es "sí merece la pena, pero no aquí", puedes rescatar el contenido a otro fichero antes de resolver.

Se resuelven con la misma lógica: git add si el fichero debe existir con el contenido que tiene en disco, git rm si no debe existir.

Las dos ramas crearon el mismo fichero con contenido distinto. Aquí sí hay marcadores dentro (Git trata el vacío como base), así que se resuelve como un conflicto de contenido normal.

Las dos ramas lo movieron a sitios distintos. Se decide la ubicación buena, se coloca el fichero ahí, se borran las otras copias y se marca todo con git add/git rm.

Un último apunte, para que sepas que existe cuando lo necesites.

rerere viene de reuse recorded resolution: "reutilizar la resolución registrada". Si lo activas, Git memoriza cómo resolviste cada conflicto y, cuando se le presenta el mismo conflicto otra vez, lo resuelve solo con tu decisión anterior.

¿Cuándo se repite un conflicto? Más veces de lo que parece: cuando fusionas main en tu rama de trabajo cada pocos días, cuando abortas una fusión y la repites, cuando rehaces una rama con rebase varias veces (módulo 5), o cuando trabajas con ramas de larga duración.

Es una herramienta de uso avanzado y tiene sus matices —conviene revisar lo que resuelve por su cuenta, sobre todo si la resolución anterior fue apresurada—, así que aquí solo la mencionamos. Con saber que existe y que se activa con esa línea es suficiente por ahora.

Error 1: dejar marcadores en el código. Confirmar un fichero con <<<<<<< dentro rompe el proyecto de forma espectacular. Git avisa si detecta marcadores al confirmar, pero no es infalible. Comprueba siempre antes de git add:

Error 2: resolver "eligiendo un lado" sin pensar. El impulso de quedarse con --ours para acabar rápido destruye el trabajo del otro lado, incluidos los cambios que se habían fusionado bien en el resto del fichero. Lee el conflicto: en la mayoría de los casos la respuesta correcta es quedarse con las dos cosas, como en el ejemplo de esta lección.

Error 3: no probar el resultado. Un conflicto resuelto puede compilar y aun así estar mal: variables que quedan sin usar, funciones duplicadas, lógica que se ejecuta dos veces. Ejecuta la aplicación o las pruebas antes de confirmar.

Error 4: entrar en pánico y borrar el repositorio. Es más habitual de lo que debería. git merge --abort deja todo exactamente como estaba. No hay ninguna situación de conflicto de la que no se pueda salir.

Error 5: confundir --ours/--theirs durante un conflicto con -X ours/-X theirs. Los primeros actúan sobre un fichero concreto, con la fusión ya parada. Los segundos son una política global que se aplica antes. Y en un rebase, además, los papeles de ours y theirs se invierten respecto a lo que uno esperaría (lección 05-01).

Consejo 1: activa zdiff3 hoy mismo. Ver el ancestro común cambia por completo la calidad de tus resoluciones:

Consejo 2: conflictos pequeños y frecuentes en lugar de grandes y raros. La mejor técnica para resolver conflictos es tener menos. Ramas de vida corta, integraciones frecuentes y traer main a tu rama cada pocos días convierten un conflicto de 300 líneas en cinco de tres.

Consejo 3: si el conflicto es enorme, aborta y estudia. Antes de pelearte con él, entiende por qué está ahí:

A veces la conclusión es que hay que hablar con la otra persona antes de tocar nada. Esa también es una respuesta válida.

Consejo 4: documenta la resolución en el mensaje del commit de fusión. Un commit de fusión con conflictos contiene decisiones humanas que no están en ningún otro sitio. Explicar en tres líneas qué chocaba y qué se decidió ahorra arqueología a quien venga después.

Consejo 5: cuando toque decidir código ajeno, pregunta. Si el conflicto está en código que no conoces, resolverlo "a ojo" es una apuesta. Un mensaje de treinta segundos a quien lo escribió sale más barato que un fallo en producción.

Monta un repositorio de pruebas, provoca un conflicto en el que las dos ramas modifiquen la misma línea, y resuélvelo combinando ambas aportaciones. Hazlo primero con el estilo de conflicto por defecto y después con diff3, y explica qué información aporta el segundo.

Provoca un conflicto modify/delete y resuélvelo de las dos formas posibles (conservando el fichero y manteniendo el borrado). Antes de decidir, muestra el contenido que aportaba la rama que lo modificó.

En un conflicto de contenido, sin abrir ningún editor, guarda en /tmp las tres versiones del fichero (base, ours y theirs) por separado y compara la base con cada una de las otras dos. Después, aborta la fusión.

Solución 1:

Con el estilo por defecto:

Con diff3:

Qué aporta diff3: deja claro que la base era "Hola " + nombre, que la rama A solo añadió los signos de exclamación y que la rama B solo añadió el parámetro y el apellido. Sin el bloque de la base, había que deducirlo comparando mentalmente los dos lados y era fácil equivocarse sobre qué se había cambiado.

Resolución que combina las dos aportaciones:

Solución 2:

Antes de decidir, vemos qué aportaba la rama:

Opción A: mantener el borrado.

Opción B: conservar el fichero (partiendo de git merge --abort y repitiendo).

La regla que resuelve todos los conflictos de árbol: git add si el fichero debe existir, git rm si no debe existir.

Solución 3:

Partiendo de un conflicto de contenido en curso sobre saludo.js:

Los dos diffs, por separado y sin marcadores, muestran con total claridad qué hizo cada rama respecto al punto de partida. Es la técnica que salva los conflictos grandes: en lugar de leer un fichero mezclado, se leen los dos cambios por separado.

Todo como estaba.

Los conflictos han dejado de ser un misterio:

• Un conflicto no es un error. Ocurre cuando las dos ramas cambiaron las mismas líneas de forma distinta desde el ancestro común. Que dos personas toquen el mismo fichero no basta: tienen que chocar en las mismas líneas.
• Git escribe marcadores en el fichero: <<<<<<< abre tu versión, ======= separa y >>>>>>> cierra la entrante. Con merge.conflictStyle en diff3 o zdiff3 aparece además el bloque ||||||| con el contenido del ancestro, que es la información que de verdad permite resolver bien.
• git status es la brújula: la sección Unmerged paths, el tipo de conflicto (both modified, deleted by us…) y los códigos cortos (UU, DU, AA). Internamente, el índice guarda tres etapas del fichero, accesibles con git show :1:, :2: y :3:, y MERGE_HEAD es lo que define que hay una fusión en curso.
• Resolver es dejar el fichero como debe quedar y marcarlo con git add (o git rm si no debe existir). No hay comando mágico: hay una decisión humana, y a menudo la respuesta correcta es combinar las dos aportaciones.
• Los atajos git checkout --ours/--theirs <fichero> (o git restore --ours/--theirs) sustituyen el fichero entero por una de las versiones. Útiles para ficheros generados; peligrosos si el fichero tenía además cambios bien fusionados.
• Nunca estás atrapado: git merge --abort restaura el estado previo por completo. --quit sale de la fusión conservando el desorden, y es para casos avanzados.
• git mergetool abre una herramienta de varios paneles con base, ours, theirs y resultado, y marca el fichero como resuelto al guardar.
• Los conflictos de árbol (borrado/modificado, añadido/añadido, renombrados) no llevan marcadores: se resuelven declarando qué debe existir.
• git rerere memoriza resoluciones y las reaplica cuando el mismo conflicto reaparece.

El proyecto está en buena forma: main contiene el contador, el filtro, la exportación a CSV, el orden alfabético y el mensaje de lista vacía. Pero el repositorio de Ana empieza a estar hecho un desastre. Tiene ramas de funcionalidades ya integradas, ramas de experimentos abandonados, ramas cuyo nombre nadie recuerda y una que se llama simplemente prueba.

En la última lección del módulo, Gestión de Ramas, pondremos orden: listar las ramas con información útil (-v, --merged, --no-merged, formatos a medida ordenados por fecha), renombrar, borrar con seguridad (-d frente a -D) y entender exactamente qué significa que Git se niegue a borrar una rama. Veremos también las convenciones de nombres —qué caracteres admite Git y qué prefijos usa la gente— y cerraremos el módulo con el problema que llevamos toda la lección esquivando: todo esto ocurre en un único portátil.