¿Qué es un conflicto de merge en Git y cómo resolverlo sin perder cambios?
Publicado el 2026-10-20 por frfrand
Cómo aparecen los conflictos de Git, qué significan los marcadores de conflicto y cómo resolverlos con pruebas y sin descartar trabajo.
Un conflicto de merge ocurre cuando Git no puede decidir de forma automática cómo combinar ciertos cambios de dos líneas de desarrollo. No significa que se hayan perdido archivos ni que alguien haya programado mal: significa que hace falta una decisión humana.
Es habitual cuando dos personas modifican las mismas líneas de un archivo, o cuando una rama elimina algo que otra modificó.
Dos personas editando el mismo cartel
Imaginá que hay un cartel que dice «Abrimos a las 9». Una persona lo cambia a «Abrimos a las 8» y otra escribe «Abrimos a las 10». No existe una respuesta correcta que una máquina pueda inferir sin conocer la intención.
Eso es parecido a un conflicto de Git. Puede reunir muchos cambios sin ayuda, pero hay situaciones donde mostrarte las alternativas es más seguro que inventar una mezcla.
¿Cómo se ve un conflicto?
Un archivo puede terminar con marcas como estas:
<<<<<<< HEAD
horario = "08:00"
=======
horario = "10:00"
>>>>>>> feature/horariosLa primera parte representa una versión y la segunda otra. Esas líneas no deberían quedar dentro del código final. Tu trabajo es decidir cuál comportamiento debe mantenerse, o escribir una tercera solución que combine las intenciones.
Los nombres y etiquetas pueden variar según la operación y herramienta.
Una forma ordenada de resolverlo
- Ejecutá
git statuspara identificar qué archivos necesitan atención. - Abrí cada conflicto y comprendé qué buscaba hacer cada rama.
- Editá el archivo hasta obtener un resultado correcto, eliminando las marcas.
- Ejecutá tests o al menos la comprobación relevante.
- Usá
git add archivopara indicar que resolviste ese conflicto. - Completá la operación de merge con el procedimiento que indique Git.
No basta con conseguir que el texto compile: los dos cambios pueden tener reglas de negocio incompatibles. Si una rama agregó un descuento y otra modificó los impuestos, combinarlas sin mirar puede producir números equivocados.
¿Puedo quedarme automáticamente con una versión?
Existen opciones que privilegian un lado u otro del conflicto. Pueden ser útiles en situaciones concretas, pero utilizarlas indiscriminadamente equivale a tirar el trabajo de una rama a la basura.
La diferencia entre resolver un conflicto y ocultarlo es entender el resultado.
¿Y si quiero cancelar?
Mientras estás en una operación de merge en curso, git merge --abort puede intentar restaurar el estado anterior. Aun así, conviene evitar comenzar operaciones complejas con modificaciones locales sin guardar, porque no siempre es posible recuperar cualquier estado automáticamente.
Antes de mezclar cambios importantes, hacé un commit coherente o guardá temporalmente tu trabajo de forma deliberada.
Cómo reducir conflictos en equipo
Integrá cambios con frecuencia, mantené las tareas separadas cuando sea razonable y evitá que varias personas editen continuamente el mismo archivo enorme. Los pull requests ayudan a conversar sobre el comportamiento esperado antes de integrar.
Un conflicto no es culpa automática de una persona. A veces simplemente indica que el trabajo avanzó en paralelo.
¿Cómo se refleja en ArduMaker?
Si una aplicación se despliega desde un repositorio en ArduMaker, resolvé los conflictos y comprobá el resultado antes de enviar la rama que se utiliza en producción. Un despliegue automático solo puede ejecutar el código que recibió: no sabe qué decisión comercial era la correcta.
En una frase: Git puede detectar cuándo no sabe mezclar cambios. Resolver el conflicto es decidir la lógica final, comprobarla y registrar la integración.
Fuentes: Git merge · Conflictos de merge en Pro Git.