Resolver conflictos de merge

Esta es la última lección del curso, y es el momento de tranquilizarte de una vez por todas: un conflicto de merge no es un error ni un fracaso, es una parte completamente normal del trabajo en equipo. La mayor parte del tiempo Git fusiona los cambios que no se superponen por su cuenta, en silencio,

Un conflicto de merge es como dos personas escribiendo con lápiz en la misma línea de una página. Git intenta combinar a todos, pero en la línea que se superpone no se atreve a adivinar: apila las dos versiones una encima de la otra y te pide que elijas cuál se queda. En el momento en que eliges y borras los marcadores, la disputa termina.

Conflicto de merge: Cuando dos ramas cambiaron las mismas líneas del mismo archivo, así que Git no puede fusionar automáticamente. Marca las dos versiones y te pide que elijas. Esto es normal, no un error.
Marcadores de conflicto: Las líneas que Git escribe en el archivo: <<<<<<< para el inicio de tu lado (HEAD), ======= como divisor, y >>>>>>> para el inicio del otro lado. Las tres hay que borrarlas al final.
HEAD (tu lado): En un conflicto, el bloque entre <<<<<<< HEAD y ======= es la versión de la rama en la que estás parado ahora: 'mi lado'.
Fusión automática: Cuando los cambios de dos ramas no tocan las mismas líneas, Git los fusiona por su cuenta sin preguntar. La mayoría de los merges pasan así, en silencio, sin ningún conflicto.
Resolver: El proceso: abrir el archivo, elegir qué se queda (un lado, el otro, o una combinación), borrar todos los marcadores, y después git add <archivo> y git commit para terminar el merge.