GIT - 5 - Conflictos entre archivos. Git merge Vs Git rebase

Normalmente los conflictos de fusión se producirán cuando dos personas han cambiado las mismas líneas en un archivo o si una de ellas ha borrado un archivo que otra está desarrollando. En estos casos Git no sabe como solventar la situación y generará un conflicto que tendremos que resolver.

Tipos de conflictos de fusión.

- Git no inicia la fusión.

Una fusión no se iniciará si Git detecta que hay cambios en el directorio de trabajo actual, no confirmados que puedan ser sobrescritos en la fusión. Vamos a crear un ejemplo de fusión que cree un error de este tipo:

chema@mcbook:~/Prueba$ git init
Initialized empty Git repository in /home/chema/Prueba/.git/
chema@mcbook:~/Prueba$ > main.py
chema@mcbook:~/Prueba$ git add .
chema@mcbook:~/Prueba$ git commit -m "Primer commit en rama main."
[main (root-commit) b19e412] Primer commit en rama main.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 main.py
 
chema@mcbook:~/Prueba$ git branch auxiliar
chema@mcbook:~/Prueba$ git switch auxiliar 
Switched to branch 'auxiliar'
chema@mcbook:~/Prueba$ echo "# Un comentario." > main.py
chema@mcbook:~/Prueba$ git add .
chema@mcbook:~/Prueba$ git commit -m "Añadida linea en archivo. Rama 
auxiliar."
[auxiliar e195481] Añadida linea en archivo. Rama auxiliar.
 1 file changed, 1 insertion(+)
 
chema@mcbook:~/Prueba$ git switch main 
Switched to branch 'main'
chema@mcbook:~/Prueba$ echo "segunda linea" > main.py
chema@mcbook:~/Prueba$ git merge auxiliar
Updating b19e412..e195481
error: Your local changes to the following files would be overwritten
     by merge:
	main.py
Please commit your changes or stash them before you merge.
Aborting

- Git falla durante la fusión.

Un fallo durante la fusión indica un conflicto entre la rama local actual y la rama que se está fusionando. Git hará lo posible para fusionar los archivos, pero te dejará cosas a solventar en los archivos con conflictos. 

Vamos a verlo con un ejemplo.

chema@mcbook:~/Prueba$ git init
Initialized empty Git repository in /home/chema/Prueba/.git/
chema@mcbook:~/Prueba$ echo "Esto es el texto inicial." > merge.txt
chema@mcbook:~/Prueba$ git add .
chema@mcbook:~/Prueba$ git commit -m "Confirmamos el contenido inicial."
[main (root-commit) e951c03] Confirmamos el contenido inicial.
 1 file changed, 1 insertion(+)
 create mode 100644 merge.txt

Ahora tenemos un repositorio con una única rama main y un poco de texto en el archivo merge.txt. A continuación creamos una nueva rama y la utilizaremos para crear una fusión conflictiva.

chema@macbook:~/Prueba$ git checkout -b nueva_rama_para_mezclar_luego
Switched to a new branch 'nueva_rama_para_mezclar_luego'
chema@macbook:~/Prueba$ echo "Contenido diferente para mezclar luego." > merge.txt
chema@macbook:~/Prueba$ git add .
chema@macbook:~/Prueba$ git commit -m "Editado el contenido del archivo merge.txt para crear un conflicto."
[nueva_rama_para_mezclar_luego 9a77225] Editado el contenido del archivo merge.txt para crear un conflicto.
 1 file changed, 1 insertion(+), 1 deletion(-)

Con esta nueva rama, hemos creado una confirmación que sobrescribe el contenido de merge.txt

chema@mcbook:~/Prueba$ git switch main
Switched to branch 'main'
chema@mcbook:~/Prueba$ echo "Contenido para añadir." >> merge.txt
chema@mcbook:~/Prueba$ git add .
chema@mcbook:~/Prueba$ git commit -m "añadido contenido a merge.txt"
[main 4f820aa] añadido contenido a merge.txt
 1 file changed, 1 insertion(+)

Esto ahora pone nuestro repositorio de ejemplo en un estado en el que tenemos dos nuevas confirmaciones. Una está en la rama main y la otra en la rama 'nueva_rama_para_mezclar_luego'. En este momento vamos a fusionarlas a ver que pasa.

chema@mcbook:~/Prueba$ git branch
* main
  nueva_rama_para_mezclar_luego
chema@mcbook:~/Prueba$ git merge nueva_rama_para_mezclar_luego 
Auto-merging merge.txt
CONFLICT (content): Merge conflict in merge.txt
Automatic merge failed; fix conflicts and then commit the result.

Como no podía ser de otra forma Git nos indica que existe un conflicto puesto que las dos ramas intentan escribir en la misma línea del archivo merge.txt.

Como identificar conflictos de fusión.

Tal como hemos visto anteriormente Git al intentar la fusión nos avisa de que existe un conflicto. 

Podemos ver más detalles usando el siguiente comando:

chema@macbook:~/Prueba$ git status
On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   merge.txt

no changes added to commit (use "git add" and/or "git commit -a")

El resultado de "git status" nos indica que existen ramas a fusionar a causa de un conflicto. El archivo merge.txt aparece ahora como modificado. Vamos a ver el archivo para ver que es lo que se ha modificado. 

chema@macbook:~/Prueba$ cat merge.txt
<<<<<<< HEAD
Esto es el texto inicial.
Contenido para añadir.
=======
Contenido diferente para mezclar luego.
>>>>>>> nueva_rama_para_mezclar_luego

Se nos muestra lo que aporta cada rama  <<<<<<< HEAD y >>>>>> nueva_rama_para_mezclar_luego, separado por los signos ==========. 

Como resolver conflictos de fusión mediante la línea de comandos.

La forma de resolver en nuestro caso el archivo es editar el archivo merge.txt. Como las líneas que intentamos fusionar no son excluyentes, quitamos los signos añadidos por Git y lo dejamos como está.

El contenido del archivo merge.txt tendría el siguiente aspecto:

Esto es el texto inicial.
Contenido para añadir.
Contenido diferente para mezclar luego.

Cuando hayas editado el archivo, utiliza git add merge.txt para prepararlo para la fusión. Finalmente terminamos la fusión con una nueva confirmación:

chema@macbook:~/Prueba$ git add merge.txt
chema@macbook:~/Prueba$ git commit -m "fusionados y resueltos los conflictos de merge.txt"
[main d1d0197] fusionados y resueltos los conflictos de merge.txt

Git merge Vs Git rebase.

Lo primero que hay que comentar sobre estos dos comandos es que ambos están diseñados para la misma función. Integrar las modificaciones o cambios que se hayan hecho en una rama con los de otra. En lo que varían es que lo hacen de forma diferente.

Imaginemos que tenemos un repositorio con dos ramas. Una llamada "main" y otra llamada "nuevas_caracteristicas". En la rama main un miembro del equipo ha hecho modificaciones y ha agregado varios commits. Por nuestra parte en la rama "nuevas_caracteristicas" nosotros hemos hecho algunas aportaciones con sus correspondientes confirmaciones. Este escenario da lugar a un historial bifurcado típico de git, tal como este:

Digamos que ahora las nuevas confirmaciones en la rama main son relevantes para nuestro rama y queremos utilizarlas. Tenemos para ello dos opciones:

1) GIT MERGE

$ git switch nuevas_caracteristicas
o
$ git checkout nuevas_caracteristicas
(Para cambiar de rama.)

$ git merge main

Esta instrucción crea una nueva confirmación de mezcla en la rama nuevas_caracteristicas que une o fusiona las historias de ambas ramas, lo que hace que quede una estructura como esta:

Usar "git merge" hace que no cambien las ramas de ninguna forma y evita los problemas que puede causar la otra opción como veremos luego.

Por otro lado esto también significa, que la rama "nuevas_características" tendrá una confirmación de commits extraña cada vez que se necesiten incorporar cambios ascendentes. Si la rama main es muy activa esto puede contaminar bastante el historial de la rama "nueva_caracteristicas" al extremo de dificultar la compresión del proyecto.

2) GIT REBASE

Como alternativa a la fusión, podemos rebasar la rama "nuevas_caracteristicas" en la rama "main" usando el siguiente comando:

$ git checkout nuevas_caracteristicas
o
$ git switch nuevas_caracteristicas
(Para cambiar de rama.)

$ git rebase main

Esto mueve toda la rama nuevas_caracteristicas para que comience en la punta de la rama main, incorporando efectivamente todas las nuevas confirmaciones de main. Pero en lugar de utilizar una confirmación de fusión, la reorganización vuelve a escribir el historial del proyecto mediante la creación de nuevas confirmaciones para cada confirmación de la rama main.

El mayor beneficio es que se obtiene un historial del proyecto mucho más limpio. Primero, se eliminan todas las confirmaciones de combinación innecesarias requeridas por "git merge". En segundo lugar, como se puede ver en el diagrama anterior, da como resultado un historial del proyecto perfectamente lineal. Puedes seguir el proyecto desde la punta hasta el inicio sin ninguna bifurcación. Esto facilita la navegación por el proyecto.

Pero también hay dos desventajas. La primera es que volver a escribir el historial del proyecto puede ser catastrófico para el flujo de trabajo cuando se esta trabajando en equipo, ya que se unifican las ramas perdiendo el historial de los commits. Además monta los commits de una rama en otra sin importar la cronología. Y aunque menos importante, la reorganización pierde el contexto proporcionado por una confirmación de combinación: no se puede ver cuando se incorporaron los cambios anteriores a la función.

Debido a esto es SUPERIMPORTANTE:

Nunca usar si este comando si se esta trabajando en un repositorio público en el que se colabora con más personas y donde las confirmaciones y su historial son muy importantes.