Entender mejor el contenido de los commit durante un conflicto de merge en Git

Al resolver un conflicto de fusión en Git es particularmente importante comprender qué sucedió en las dos versiones diferentes y si los dos contenidos diferentes pueden reconciliarse y cómo.

De hecho, las dos versiones pueden contener código que se comporte de manera muy diferente y es importante comprender lo que se está aprobando antes de continuar.

Una primera sugerencia es configurar su Git para usar el estilo "diff3" para conflictos de merge.

Si volvemos al ejemplo anterior, ejecutando git config merge.conflictstyle diff3 antes de ejecutar git merge, los marcadores agregados por Git para resaltar el contenido en conflicto cambian:

$ git config merge.conflictstyle diff3
$ git merge new_branch_to_merge_later
$ cat merge.txt
<<<<<<< HEAD
initial content to edit later
content added to previous
||||||| 0a99708
initial content to edit later
=======
new content to merge later
>>>>>>> merge-me

Respecto a la versión precedente tenemos:

• entre ||||||| y ======= el contenido en el commit principal común a los dos commit en conflicto
• entre <<<<<<< y ||||||| la versión en el branch “current”
• entre ======= y >>>>>>> la versión en el branch “incoming”

Aún con el fin de comprender lo que se está haciendo, también podría ser útil verificar los mensajes de commit de las ramas respectivas a través de git log --merge, tal vez usando la opción -p que también muestra las diferencias de los dos commit.

$ git log --merge -p merge.txt
commit 90640eb2ecab9ec63fcad24817a314df344e024c (HEAD -> main)
Author: Frank <frank@example.com>
Date:   Sat Jan 14 23:33:22 2023 +0100

    appended content to merge.txt

diff --git a/merge.txt b/merge.txt
index 3480007..c560b6f 100644
--- a/merge.txt
+++ b/merge.txt
@@ -1 +1,2 @@
initial content to edit later
+content added to previous

commit 15416df402028b78858105c84d49a86fee59e2e3 (merge-me)
Author: Me <me@example.com>
Date:   Sat Jan 14 23:31:09 2023 +0100

    edited the content for conflict

diff --git a/merge.txt b/merge.txt
index 3480007..202af08 100644
--- a/merge.txt
+++ b/merge.txt
@@ -1 +1 @@
-initial content to edit later
+new content to merge later

Además, no debe olvidarse que muchos IDE, editores de texto para desarrolladores web y aplicaciones GUI para Git ofrecen métodos visuales más atractivos para comprender las diferencias exactas entre dos commit en conflicto.

Modificar archivo en conflicto con VSCode

Abriendo un archivo que está en conflicto, el editor VSCode reconoce y destaca los marker de conflicto y ofrece varias opciones para resolver el conflicto. 

Modificar archivo en conflicto con VSCode
 

También está disponible una vista especial que le permite ver tanto las dos versiones "originales" como la versión que se está reescribiendo.

NOTA: Curiosamente, aunque Git usa el nuestro y el de ellos, algunas interfaces de usuario de Git han optado por usar “current” e “incoming” respectivamente, que hemos tomado prestados para esta guía. No olvides que la acción de fusionar dos ramas tiene una "dirección". Desde este punto de vista, la nomenclatura current/incoming es más explícita en el caso de que, por ejemplo, se fusione una rama con main en la que hay "nuestros" commit y el conflicto es con los commit realizados por otros desarrolladores: en este caso, de hecho, para Git, los commit de otros que ya están en main y los nuestros serían nuestros commit en la rama.

Una vez resuelto el conflicto, el resultado será una nueva versión del archivo y, en concreto, una nueva versión de ese grupo de líneas y, al final de la fusión, habrá que comprobar que el código sigue siendo correcto y laboral.

Por lo tanto, siempre es importante entender lo que uno está aceptando al resolver un conflicto de fusión, pero sobre todo también es importante saber cuándo es apropiado interrumpir la fusión y volver sobre los pasos de uno, tal vez consultando al colega o colegas para entender juntos qué versión de los cambios será finalmente la que se incluirá en el repositorio.