Un Merge Conflict es una pausa en el proceso de integración que ocurre cuando Git detecta dos modificaciones contradictorias en un mismo archivo y requiere tu intervención manual.
Estás intentando integrar una rama con git merge (o bajando el código de un compañero con git pull). Todo parece ir bien hasta que la terminal te suelta el mensaje:
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
A nivel técnico, un conflicto no es un “error”, es Git siendo conservador. Ha encontrado dos versiones distintas para la misma línea de código y, como no puede adiviniar cuál es la buena, pausa la operación y te pasa la pelota a ti.
En este artículo vamos a entender la anatomía de un conflicto, cómo interpretar las marcas que Git inyecta en tus archivos y, cómo resolverlos visualmente aprovechando la interfaz de VS Code.
¿Por qué ocurre un conflicto?
Un conflicto de fusión ocurre cuando hay dos cambios diferentes sobre el mismo elemento.
Por ejemplo:
- Dos personas (o tú en dos ramas distintas) habéis modificado la misma línea del mismo archivo de forma diferente.
- Una persona ha modificado un archivo y la otra lo ha borrado.
En estos casos, Git no puede decidir si el cambio bueno es A o la B. No puede resolver automáticamente la fusión. Así que pausa la fusión y deja el archivo en un estado especial.
Resolviendo conflictos en VS Code
Es posible arreglar un conflicto borrando manualmente las líneas con los símbolos <<<< y ====. Pero básicamente hacerlo sin GUI es un infierno.
Visual Studio Code detecta automáticamente este formato y nos ofrece una interfaz visual para arreglarlo mucho más fácil.
Cuando abras el archivo en conflicto en VS Code, verás que resalta los bloques en colores y te ofrece unos botones encima del conflicto. Las opciones son:
Si haces clic aquí, VS Code se queda con tu versión (la de HEAD) y borra la versión que venía de la otra rama.
Es decir, “Mi código es el bueno, el del otro está mal”.
Si haces clic aquí, VS Code se queda con la versión de la otra rama y borra la tuya.
Es decir, “Lo que viene de la rama feature es más correcto, sobrescribe lo mío”.
Mantiene los dos bloques de código, uno debajo del otro, y borra solo las marcas de Git.
Es decir, “Necesito las dos líneas”.
Normalmente tendrás que reordenar el código manualmente después de esto para que tenga sentido.
Cerrando el conflicto
Has usado los botones de VS Code, el archivo ya se ve bien. Ya no hay conflictos. Pero si miras tu terminal, Git sigue diciendo que está en estado “MERGING”.
Git no sabe que ya has terminado de editar el archivo en VS Code, tienes que decírselo. El proceso completo es:
Resuelves el conflicto en el editor.
Guardas el archivo (Ctrl+S).
Vas a la terminal y ejecutas:
git add nombre_del_archivo
Al añadirlo al Stage, le dices a Git: “Este archivo ya está arreglado, márcalo como resuelto”
Una vez arreglados todos los archivos conflictivos, finalizas la fusión con:
git commit
Si no pones el mensaje con el parámetro -m, Git te generará uno automático tipo “Merge branch ‘feature’ into main”.
El botón del pánico: git merge --abort
A veces, empiezas a resolver conflictos, te lías, borras algo que no debías y el código deja de tener sentido. Te agobias. Quieres salir de ahí.
Si quieres cancelar la fusión y dejarlo todo exactamente como estaba antes de escribir git merge, ejecuta:
git merge --abort
El repositorio volverá al estado limpio anterior al intento de fusión.
El mejor conflicto es el que no se crea
Los Merge Conflict es el problema más frecuente del trabajo colaborativo. Dependiendo del tamaño de los cambios, un conflicto puede ser un trámite de cinco segundos o una liada monumental.
La forma de resolver los conflictos es NO GENERARLOS. Para eso la mejor forma es
- Comunicación en el equipo. Poneros de acuerdo en lo que toca cada quién.
- Tener una arquitectura limpia, que facilite el trabajo colaborativo.
