Conflictos básicos

La palabra "conflicto" suena intimidante. Pero en Git, un conflicto es simplemente una situación donde Git te dice: "Oye, dos personas cambiaron lo mismo y no sé con cuál quedarme. Decide tú." Nada se rompe, nada explota. Es un paso más del proceso, y una vez que lo entiendas, lo vas a resolver en segundos.

¿Qué es exactamente un conflicto?

Un conflicto ocurre cuando dos ramas modifican las mismas líneas del mismo archivo de forma diferente, y luego intentas fusionarlas con git merge. Git es muy inteligente: si una rama cambia el encabezado y otra cambia el pie de página, Git fusiona ambos cambios sin problemas. El conflicto solo aparece cuando Git no puede decidir automáticamente qué versión mantener.

¿Cuándo aparecen conflictos?

Los conflictos ocurren en situaciones muy específicas:

• Dos ramas cambian la misma línea del mismo archivo de forma diferente.
• Una rama elimina un archivo que otra rama modificó.

Y lo más importante: los conflictos NO ocurren cuando dos ramas modifican archivos diferentes. Git maneja eso automáticamente sin ningún problema. Tampoco ocurren si dos ramas modifican el mismo archivo pero en líneas distintas.

Vamos a crear un conflicto a propósito

La mejor forma de perderle el miedo a los conflictos es provocar uno tú mismo. Vamos a hacerlo paso a paso con nuestro proyecto de Café Estelar.

Paso 1: Modificar el h1 en main

Asegúrate de estar en la rama main y abre index.html. Cambia el <h1> principal:

<h1>Café Estelar — Edición Gourmet</h1>

Guarda el archivo y haz un commit:

git add index.html
git commit -m "Cambiar título a Edición Gourmet"

Paso 2: Crear una rama y hacer un cambio diferente

Ahora crea una nueva rama y cámbiate a ella:

git checkout -b feature/nuevo-nombre

Abre index.html y cambia el mismo <h1>, pero con un texto diferente:

<h1>Café Estelar — Sabores del Universo</h1>

Guarda y haz un commit:

git add index.html
git commit -m "Cambiar título a Sabores del Universo"

Paso 3: Intentar fusionar

Vuelve a main e intenta fusionar la rama:

git checkout main
git merge feature/nuevo-nombre

Y ahí lo tienes. Git te va a mostrar algo como esto:

Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

No te asustes. Git te está diciendo exactamente qué pasó: encontró un conflicto en index.html y necesita que tú lo resuelvas.

¿Cómo se ve un conflicto en el archivo?

Si abres index.html, verás algo así en la zona del conflicto:

<<<<<<< HEAD
<h1>Café Estelar — Edición Gourmet</h1>
=======
<h1>Café Estelar — Sabores del Universo</h1>
>>>>>>> feature/nuevo-nombre

Estos marcadores te dicen exactamente qué está pasando:

• <<<<<<< HEAD — marca el inicio del conflicto. Lo que viene después es la versión de tu rama actual (main).
• ======= — separa las dos versiones.
• >>>>>>> feature/nuevo-nombre — marca el final del conflicto. Lo que está entre el separador y esta línea es la versión de la rama entrante.

En resumen: arriba está lo tuyo (HEAD, la rama donde estás), abajo está lo que intentas fusionar.

Cómo resolver el conflicto

Resolver un conflicto es tan simple como editar el archivo. Sigue estos pasos:

1. Abre el archivo con el conflicto.
2. Elimina los marcadores de conflicto (<<<<<<<, =======, >>>>>>>).
3. Deja el código como quieres que quede. Puedes quedarte con una versión, con la otra, o combinar ambas.
4. Guarda el archivo.
5. Marca como resuelto con git add y haz el commit.

Por ejemplo, si decides que te gusta más "Sabores del Universo", dejas el archivo así:

<h1>Café Estelar — Sabores del Universo</h1>

O si prefieres combinar ambas ideas:

<h1>Café Estelar — Sabores Gourmet del Universo</h1>

Después de editar, marca el conflicto como resuelto y confirma:

git add index.html
git commit -m "Resolver conflicto en título principal"

Listo. El conflicto está resuelto y el merge se completó.

Tu editor te lo pone aún más fácil

Si usas Zed (el editor que recomendamos en este curso), verás que detecta los conflictos automáticamente y te muestra botones encima de cada uno. VS Code también lo hace. La mayoría de editores modernos tienen esta funcionalidad:

• Accept Current Change — se queda con la versión de HEAD (tu rama actual).
• Accept Incoming Change — se queda con la versión de la rama entrante.
• Accept Both Changes — incluye las dos versiones, una después de la otra.
• Compare Changes — abre una vista comparativa lado a lado.

Estos botones hacen exactamente lo mismo que editar el archivo a mano, pero de forma más visual. Úsalos cuando tengas prisa, pero es importante que entiendas qué está pasando por debajo.

Consejos para evitar conflictos

Los conflictos son normales, pero puedes reducir su frecuencia con buenas prácticas:

• Comunica con tu equipo quién está trabajando en qué archivos. Si dos personas tocan el mismo archivo a la vez, es cuestión de tiempo que haya un conflicto.
• Haz pull con frecuencia. Cuanto más actualizado esté tu código local, menos diferencias habrá con la rama principal.
• Mantén las ramas de corta duración. Una rama que vive dos semanas acumula muchas diferencias. Una rama que vive dos horas, muy pocas.
• Haz commits pequeños y enfocados. Un commit que cambia 3 líneas es mucho más fácil de fusionar que uno que cambia 300.

Resumen de la sección Git

Esta es la última lección de la sección de Git, así que vamos a repasar todo lo que has aprendido en estas 7 lecciones:

Has pasado de no saber qué es Git a poder crear repositorios, trabajar con ramas, subir código a GitHub y resolver conflictos. Eso es exactamente lo que necesita un desarrollador en su día a día. Git tiene muchas más funcionalidades avanzadas, pero con lo que sabes ahora puedes trabajar de forma profesional en cualquier proyecto.

Git no es algo que aprendes una vez y ya. Es una herramienta que dominas con la práctica. Cada proyecto que hagas, cada rama que crees, cada conflicto que resuelvas te va a hacer mejor. Así que no dejes de usarlo: a partir de ahora, cada proyecto que crees debería empezar con git init.