Resolver conflictos en GitHub

Cuando varias personas trabajan sobre el mismo proyecto, es posible que realicen cambios diferentes sobre una misma parte de un archivo. Cuando GitHub no puede determinar automáticamente qué cambio debe conservar, se produce un conflicto.

Resolver conflictos en GitHub consiste en revisar esas diferencias, decidir qué código debe mantenerse y actualizar la rama para que los cambios puedan integrarse correctamente.

1. ¿Qué significa Resolver conflictos en GitHub?

Un conflicto en GitHub ocurre cuando dos ramas contienen cambios incompatibles en una misma parte de un archivo y Git no puede combinarlos automáticamente.

Por ejemplo, imaginemos que en la rama main existe:

<h1>Mi página web</h1>Lenguaje del código: HTML, XML (xml)

Mientras que en otra rama alguien modifica esa misma línea:

<h1>Mi sitio web</h1>Lenguaje del código: HTML, XML (xml)

Si ambas modificaciones intentan incorporarse al mismo lugar del proyecto, Git no puede decidir cuál de las dos versiones debe utilizar.

En ese momento se produce un conflicto y será necesario resolverlo manualmente.

Un conflicto no significa que el repositorio esté dañado. Significa que Git necesita que una persona decida cómo combinar los cambios.

1.1. ¿Cuándo aparece un conflicto en GitHub?

Los conflictos pueden aparecer en diferentes momentos del flujo de trabajo.

Uno de los casos más habituales ocurre al crear una Pull Request.

El flujo puede ser:

Rama principal
      ↓
Crear rama
      ↓
Realizar cambios
      ↓
Crear Pull Request
      ↓
Comparar ramas
      ↓
¿Existen conflictos?
     ↙        ↘
   No          Sí
   ↓            ↓
Merge       Resolver
              conflicto

Si GitHub puede combinar los cambios automáticamente, la Pull Request puede continuar hacia el merge.

Si no puede hacerlo, GitHub indica que existen conflictos que deben resolverse.

1.2. ¿Cómo saber si una Pull Request tiene conflictos?

Cuando una Pull Request tiene conflictos, GitHub muestra información indicando que existen cambios que deben resolverse antes de realizar el merge.

Dentro de la Pull Request se puede encontrar una indicación similar a:

This branch has conflicts that must be resolved

Esto significa:

Esta rama tiene conflictos que deben resolverse.

GitHub también puede mostrar opciones relacionadas con la resolución del conflicto.

La situación puede representarse así:

main
  │
  ├── cambio A
  │
  └── cambio B
       ↑
       │
   conflicto
       │
       ↓
 Pull Request

2. ¿Cómo resolver conflictos en GitHub? Paso a paso

Resolver un conflicto en GitHub consiste en revisar los cambios que entran en conflicto, decidir qué versión debe conservarse y confirmar la solución antes de realizar el merge de la Pull Request.

En conflictos sencillos, GitHub permite realizar todo el proceso directamente desde el navegador. El procedimiento general es el siguiente.

2.1. Abrir la Pull Request

Primero debemos entrar en la Pull Request donde GitHub ha detectado el conflicto.

En ella veremos que la rama no puede combinarse automáticamente con la rama de destino.

Por ejemplo:

feature-login  →  main

        ↓

No se puede realizar el merge automáticamente

GitHub mostrará un aviso indicando que existen conflictos que deben resolverse.

2.2. Identificar los archivos que tienen conflictos

El siguiente paso es revisar qué archivos están provocando el problema.

Un repositorio puede tener muchos archivos modificados, pero solamente algunos pueden contener conflictos.

Por ejemplo:

Archivos modificados

✓ index.html
✓ estilos.css
⚠ app.js
✓ README.mdLenguaje del código: CSS (css)

El archivo marcado como conflictivo contiene cambios que Git no pudo combinar automáticamente.

2.3. Seleccionar «Resolve conflicts»

Si GitHub permite solucionar el conflicto desde la interfaz web, aparecerá la opción Resolve conflicts.

Al seleccionarla, GitHub abre un editor donde podemos visualizar y modificar directamente los archivos afectados.

Esto permite solucionar conflictos sencillos sin tener que descargar el repositorio y trabajar localmente.

2.4. Revisar las partes en conflicto

Dentro del archivo encontraremos unas marcas que Git utiliza para indicar las diferentes versiones del código.

Por ejemplo:

<<<<<<< HEAD
<h1>Curso de GitHub</h1>
=======
<h1>Curso completo de GitHub</h1>
>>>>>>> nueva-rama

En este ejemplo existen dos versiones diferentes del mismo contenido:

<h1>Curso de GitHub</h1>Lenguaje del código: HTML, XML (xml)

y:

<h1>Curso completo de GitHub</h1>Lenguaje del código: HTML, XML (xml)

Ahora debemos decidir cuál de las dos versiones queremos utilizar.

2.5. Decidir qué cambios conservar

Este es el paso más importante de todo el proceso.

No debemos eliminar una versión simplemente porque Git la marque como conflicto. Primero debemos entender qué cambio realizó cada rama.

Tenemos diferentes posibilidades.

2.5.1. Conservar el cambio actual

Podemos mantener:

<h1>Curso de GitHub</h1>Lenguaje del código: HTML, XML (xml)

si consideramos que esa es la versión correcta.

2.5.2. Conservar el cambio de la otra rama

También podemos utilizar:

<h1>Curso completo de GitHub</h1>Lenguaje del código: HTML, XML (xml)

si ese cambio es el que queremos incorporar al proyecto.

2.5.3. Combinar ambos cambios

En algunos casos podemos crear una tercera versión que combine ambas modificaciones:

<h1>Curso completo de GitHub desde cero</h1>Lenguaje del código: HTML, XML (xml)

La decisión dependerá de la lógica y de las necesidades del proyecto.

2.6. Eliminar las marcas del conflicto

Una vez decidido cuál será el código definitivo, debemos eliminar las marcas utilizadas por Git:

<<<<<<<
=======
>>>>>>>

Por ejemplo, debemos pasar de:

<<<<<<< HEAD
<h1>Curso de GitHub</h1>
=======
<h1>Curso completo de GitHub</h1>
>>>>>>> nueva-rama

a:

<h1>Curso completo de GitHub</h1>Lenguaje del código: HTML, XML (xml)

Las marcas de conflicto no deben permanecer en el código final.

2.7. Revisar todo el archivo

Antes de marcar el conflicto como resuelto, es recomendable revisar nuevamente el archivo completo.

Debemos comprobar que:

• El código tenga la sintaxis correcta.
• No hayamos eliminado accidentalmente contenido necesario.
• Los cambios de ambas ramas se hayan integrado correctamente.
• No hayan quedado marcas como <<<<<<<, ======= o >>>>>>>.
• La solución tenga sentido dentro del proyecto.

Este paso es especialmente importante cuando el conflicto afecta código HTML, CSS, JavaScript u otros archivos de programación.

2.8. Marcar el conflicto como resuelto

Cuando hayamos terminado de modificar el archivo, GitHub permite indicar que el conflicto ya fue solucionado.

La interfaz mostrará una opción como Mark as resolved.

Al utilizarla, estamos indicando a GitHub que hemos revisado y solucionado manualmente esa diferencia.

Si existen varios archivos con conflictos, tendremos que resolverlos todos.

2.9. Confirmar la resolución

Después de resolver los conflictos, debemos confirmar los cambios.

GitHub guardará la resolución realizada en la rama correspondiente.

En este momento es importante recordar que resolver el conflicto y realizar el merge son operaciones diferentes.

Primero:

Resolver conflicto
       ↓
Confirmar solución

Y posteriormente:

Revisar Pull Request
       ↓
Merge

2.10. Revisar nuevamente la Pull Request

Una vez solucionado el conflicto, debemos volver a la Pull Request y comprobar que el problema haya desaparecido.

También conviene revisar:

• Los archivos modificados.
• Las diferencias entre las ramas.
• Los comentarios de la revisión.
• Las comprobaciones automáticas.
• Los posibles errores del proyecto.

Si todo funciona correctamente, la Pull Request estará lista para continuar con el proceso de integración.

2.11. Realizar el merge

Cuando el conflicto haya sido solucionado y hayamos comprobado que los cambios son correctos, podemos realizar el merge de la Pull Request.

El proceso completo puede resumirse así:

Abrir Pull Request
        ↓
Detectar conflicto
        ↓
Identificar archivos afectados
        ↓
Resolve conflicts
        ↓
Revisar las diferencias
        ↓
Elegir o combinar cambios
        ↓
Eliminar marcas del conflicto
        ↓
Mark as resolved
        ↓
Confirmar cambios
        ↓
Revisar Pull Request
        ↓
Realizar mergeLenguaje del código: JavaScript (javascript)

¿Qué pasa si GitHub no permite resolver el conflicto desde el navegador?

No todos los conflictos pueden resolverse directamente desde GitHub. Cuando el conflicto es demasiado complejo o la interfaz no ofrece la opción de resolverlo, podemos actualizar el repositorio local y resolverlo utilizando Git y un editor como Visual Studio Code.

En ese caso, el proceso cambia ligeramente:

GitHub
  ↓
Pull Request con conflicto
  ↓
Actualizar repositorio local
  ↓
Resolver conflicto con Git
  ↓
Revisar en VS Code
  ↓
Probar proyecto
  ↓
Commit
  ↓
Push
  ↓
GitHub actualiza la Pull Request
  ↓
Merge

Este método ofrece mayor control sobre los archivos y resulta especialmente útil cuando existen varios conflictos o cuando la resolución requiere modificar manualmente diferentes partes del proyecto.

Lo más importante es recordar que resolver un conflicto no consiste simplemente en elegir una versión: debemos comprender qué cambios están enfrentados, decidir cuál debe ser el resultado final y comprobar que el proyecto continúe funcionando correctamente antes de realizar el merge.

3. Flujo completo resumido

Podemos resumir todo el proceso de esta manera:

Crear una rama
      ↓
Realizar cambios
      ↓
Crear Pull Request
      ↓
GitHub compara las ramas
      ↓
¿Hay conflicto?
   ↙          ↘
 No            Sí
 ↓              ↓
Merge       Analizar cambios
                ↓
          Resolver conflicto
                ↓
          Revisar código
                ↓
             Probar
                ↓
        Actualizar Pull Request
                ↓
              Merge

Este flujo es fundamental para trabajar correctamente con GitHub cuando un proyecto tiene varias ramas y varias personas realizan cambios simultáneamente.

Conclusión

Resolver conflictos en GitHub es una parte normal del trabajo colaborativo con Git y GitHub. Los conflictos aparecen cuando Git no puede combinar automáticamente cambios realizados sobre una misma parte del proyecto.