Conflictos de fusión: no entres en pánico, comprende y resuelve

Tres tipos de conflictos de fusión

• De contenido: cambios en las mismas líneas
• De renombrado: un archivo se modificó y renombró
• De eliminación: un archivo se borró en una rama y se modificó en otra
• Los renombrados son los más complicados para Git
• Verifica el historial del archivo ante conflictos sospechosos

Imagina que estás trabajando en un proyecto importante y de repente Git reporta un conflicto. El primer paso para resolverlo es identificar su tipo. Los conflictos de contenido ocurren cuando se modifican las mismas líneas en diferentes ramas. Los renombrados son más complejos: un desarrollador cambia el nombre del archivo mientras otro edita su contenido. El tercer tipo son las eliminaciones, cuando un archivo desaparece en una rama pero continúa existiendo en otra. Los renombrados suelen ser los más problemáticos porque Git no siempre rastrea correctamente el historial después de cambiar el nombre. Por eso, ante conflictos sospechosos, siempre revisa el historial de cambios de los archivos.

Anatomía de un conflicto complejo

• Los marcadores <<<<<<< muestran tus cambios
• ======= separa tu versión de la de otros
• >>>>>>> marca el final del bloque conflictivo
• git status mostrará todos los archivos problemáticos
• git diff — comparación detallada de cambios

Supongamos que estás fusionando la rama feature en main y ves un mensaje de conflicto. Abre los archivos problemáticos: notarás marcadores especiales. Todo lo que está entre <<<<<<< HEAD y ======= son tus cambios. Entre ======= y >>>>>>> feature están los cambios de la rama que estás fusionando. Usa git status para ver todos los archivos en conflicto, y git diff para una vista detallada de las diferencias. Recuerda: los marcadores no son un error, sino una guía que indica dónde debes tomar una decisión.

#!/bin/bash
# conflict_analysis.sh

echo "Creando un repositorio de prueba"
mkdir conflict-demo && cd conflict-demo
git init

echo "Creando archivo y primer commit en main"
echo 'Line 1' > file.txt
echo 'Line 2' >> file.txt
git add . && git commit -m 'Commit inicial'

echo "Creando rama feature y modificando primera línea"
git checkout -b feature
sed -i 's/Line 1/Line 1 modificado en feature/' file.txt
git commit -am 'Modificar línea 1 en feature'

echo "Volviendo a main y modificando la misma línea"
git checkout main
sed -i 's/Line 1/Line 1 modificado en main/' file.txt
git commit -am 'Modificar línea 1 en main'

echo "Intentando fusionar ramas"
git merge feature || echo '¡Conflicto!'

echo "\nMostrando estado:"
git status --short

echo "\nMostrando archivo conflictivo:"
cat file.txt

Estrategias para resolver conflictos

• Edición manual: eliminar marcadores, conservar lo necesario
• Herramientas GUI: meld, kdiff3 para comparación visual
• --ours/--theirs: aceptar tu versión o la de otros
• En rebase, los conflictos se resuelven por cada commit
• Después de resolver — no olvides git add y git commit

Cuando se detecta un conflicto, tienes varias opciones. Puedes abrir el archivo manualmente y editarlo, eliminando los marcadores y conservando el código deseado. Para los más visuales, herramientas como meld o kdiff3 son ideales, ya que muestran tres versiones del archivo simultáneamente. Si estás seguro de tus cambios, usa git checkout --ours para mantener tu versión, o --theirs para aceptar la de otros. Ten especial cuidado con rebase: aquí los conflictos pueden surgir en cada commit que se está reubicando.

#!/bin/bash
# resolve_strategies.sh

echo "Método 1: Resolución manual"
echo 'Edita el archivo eliminando los marcadores de conflicto'
echo 'Luego ejecuta: git add file.txt'

echo "\nMétodo 2: Aceptar nuestra versión"
git checkout --ours file.txt

echo "\nMétodo 3: Aceptar su versión"
git checkout --theirs file.txt

echo "\nMétodo 4: Usar herramienta de fusión"
echo 'git mergetool --tool=meld'

echo "\nDespués de elegir el método, completa la fusión:"
echo 'git commit -m "Resolve merge conflict"'