Cuando trabajas en equipo con Git, tarde o temprano dos personas tocarán el mismo archivo y aparecerá un merge conflict. Saber resolver conflictos de ramas en Git es la diferencia entre frenar al equipo o mantener el flujo de trabajo intacto. Aquí verás cómo provocar uno a propósito y solucionarlo línea por línea.
¿Por qué ocurre un conflicto de ramas en Git?
Un conflicto aparece cuando dos ramas modifican la misma porción de un archivo y Git no puede decidir cuál versión conservar. En lugar de elegir por ti, te entrega el control para que tú definas la versión final.
Esto pasa más seguido de lo que parece cuando varias personas trabajan en paralelo sobre el mismo repositorio. La buena noticia: Git marca cada conflicto con señalizaciones claras para que sepas exactamente qué cambió y desde dónde [01:27].
¿Qué es un conflicto en Git? Es una situación en la que dos ramas modifican las mismas líneas de un archivo y Git te pide decidir manualmente cuál cambio se queda en la versión final.
¿Cómo crear un conflicto controlado para practicar?
La mejor forma de aprender a resolver un merge conflict es provocarlo tú mismo. Estos son los pasos que sigo en la terminal para forzar el escenario [01:39]:
- Verifica tu rama actual con
git branch. Si solo tienes main, perfecto.
- Crea un archivo nuevo con
nano conflict.txt y escribe línea original dentro.
- Registra el archivo con
git add y git commit -m "archivo de conflicto creado".
- Crea una rama nueva con
git checkout -b developer para trabajar en paralelo.
- Edita
conflict.txt desde developer, escribe cambios desde la rama dev y haz commit.
- Vuelve a
main con git checkout main o git switch main.
- Edita el mismo archivo en
main, escribe segundo cambio desde main y haz commit.
Con esto tienes dos ramas que modificaron el mismo archivo en la misma línea. El terreno está listo para el conflicto.
¿Sirve igual git switch que git checkout?
Sí. Tanto git checkout como git switch te permiten cambiar de rama y hacen exactamente lo mismo en este contexto [03:36]. La diferencia es que git switch es más reciente y está pensado solo para ramas, mientras que git checkout cubre más operaciones.
¿Cómo resolver el conflicto al hacer merge?
Desde main, ejecuta git merge developer. Git intentará fusionar y te avisará que hay un conflicto en conflict.txt. Aquí es donde entra la parte interesante [04:30].
Abre el archivo con nano conflict.txt y verás algo así:
<<<<<<< HEAD
segundo cambio desde main
cambios desde la rama dev
developer
La sección marcada con HEAD es el último cambio de tu rama principal. La sección de abajo corresponde a la rama developer. Tu trabajo es decidir qué se queda.
Puedes:
- Conservar solo el cambio de
main y borrar el bloque de developer.
- Conservar solo el cambio de developer y borrar el bloque de
HEAD.
- Combinar ambos en una versión nueva.
- Escribir algo completamente distinto si así lo necesita el proyecto.
Lo importante: elimina las señalizaciones <<<<<<<, ======= y >>>>>>> antes de guardar. Esas marcas son guías de Git, no parte de tu código.
¿Qué significa HEAD en un conflicto de Git? HEAD apunta al último commit de la rama en la que estás parado. En un merge, indica cuál de los bloques pertenece a tu rama actual.
¿Cómo cerrar el merge y dejar limpio el repositorio?
Después de editar el archivo, guarda los cambios y verifica el estado con git status. Verás el mensaje ambos modificados en conflict.txt, lo que confirma que Git ya detectó tu intervención manual [05:35].
Desde ahí, los pasos finales son directos:
- Ejecuta
git add conflict.txt para marcar el conflicto como resuelto.
- Haz
git commit -m "nuevos cambios" para registrar la fusión.
- Vuelve a correr
git merge developer si fuera necesario, o confirma que el merge ya quedó cerrado.
Con esto, la versión final del documento queda unificada dentro de main.
¿Qué hago con la rama después de resolver el conflicto?
Una vez fusionada, elimina la rama adicional para evitar conflictos posteriores en commits futuros [06:05]. Una rama vieja que sigue viva suele ser fuente de nuevos merge conflicts cuando alguien la retoma sin actualizarla.
Puedes borrarla con git branch -d developer cuando ya esté integrada a main. Así mantienes tu repositorio limpio y tu equipo enfocado solo en las ramas activas.
¿Te ha tocado resolver un conflicto de Git en un proyecto real? Cuéntame en los comentarios cómo lo manejaste y qué estrategia usas con tu equipo para evitar que se repita.
