Estás muy orgulloso de ser un desarrolador. Inviertes mucho tiempo trabajando en cada feature. Escribes pruebas unitarias preciosas para cada una de las condiciones de los requerimientos (antes de escribir la primera línea de código que no es de tests, cierto? Que viva el TDD!)... y ves las pruebas fallar.... apenas puedes aguantar las ganas de corregirlas. Te sientas a escribir el código del requermiento (ahora sí) y ves como las pruebas otra vez están pasando sin problemas. Empujas los cambios y creas un PR.... una secuencia de cambios que se explican solos... lo más próximo que el código pueda estar de ser comparado con poesía. El PR es mezclado en la rama principal y la vida es bella. Felicitaciones de todos los conocidos. Vuelves a seguir programando otro requerimiento... luego de tomarte una deliciosa taza de café recien colado, por supuesto.
Pasan 3 semanas. Te halan a una reunión telefónica.... necesito especificar que sin aviso? O sea, de qué otra forma te podrían meter en una reunión con todos los pesos pesados del equipo de desarrollo y del equipo de soporte de producción? Luego de algunos minutos de tratar de obtener algún contexto, finalmente te das cuenta de que todas esas voces estresadas repartidas por 6 zonas horarias en 3 continentes están refiriénsode al bello... poema que escribiste antes. Está roto.... EN PRODUCCIÓN. SE NECESITA UN ARREGLO... YA!!!
Luego de lograr que tu pulso vuelva parcialmente a la normalidad, te sientas a analizar el código de lo que está en producción y, pero qué??? El código de tu PR no está completo!!! Le falta una parte.... en realidad, le falta bastante. Pero cómo??? Luego de analizar un poco más te das cuenta de que hubo un merge cuando se iba a cortar la rama de producción y el código del PR fue.... bueno, destruido mientras se resolvía conflictos. Así que estás en la línea de fuego... y ni si quiera es tu culpa. Ah, y antes de que lo olvide... recuerdas esas bellísimas pruebas que serían la envidia de Jorge Luis Borges que te tomó tanto tiempo escribir? Bueno, la mitad de ellas fueron borradas porque estaban fallando luego de la carnicería de los conflictos y quien quiere ver pruebas fallidas cuando se quiere lanzar a producción?
Resolver conflictos es una materia engañosa. Los desarrolladores gastan tanto tiempo escribiendo código. Agregando, modificando y borrando código... moviéndolo, reformateándolo, reformándolo, mejorándolo 1. Dado que nos hemos movido a Sistemas de Control de Versiones Distribuidos (o DVCS por sus siglas en inglés), especialmente git, estamos ejecutando operaciones que pueden generar conflictos con mucha más frecuencia así que, de hecho, la mayoría de los desarrolladores gastamos algo de nuestro tiempo resolviendo conflictos, a veces dolorosamente, cada tanto.
Lo que normalmente sucede es que un proyecto es desarrollado por múltiples desarrolladores de forma independiente y luego todo este trabajo separado se tiene que juntar. Cuando git trata de mezclar el desarrollo que se hizo en dos direcciones diferentes, él trata lo mejor que puede de resolver como juntar todo de forma programada.... sin embargo, hay situaciones en las que git tirará la toalla y levantará la mano para pedir ayuda de una persona para que mire el código y lo arregle. Cuando esto sucede, se dice que hay un conflicto.
No hay nada malo en que haya conflictos. En los viejos tiempos, cuando los Sistema de Control de Versiones Centralizados eran la norma, se tenía estás ramas largas que se mezclaban muy poco por el tiempo que toma resolver todos los conflictos. Sin embargo, con el advenimiento de los DVCSs, mezclar se hace de forma mucho más frecuente y hay muchas más oportunidades de generar conflictos con operaciones que no se usaban con frecuencia anteriormente (si es que existían en los sistemas centralizados) como cherry-pick, rebase o stash.
Luego de gastar algo de tiempo resolviendo conflictos, los desarrolladores tienden a hacer todo lo que sea posible por tratar de evitarlos por el tiempo que toma y por lo complejo que puede ser resolverlos, especialmente cierto si el código que se está trabajando no le es familiar a la persona que está resolviendo el conflicto pero, una vez que el conflicto está delante de ti, no hay mucho que se pueda hacer para evitarlo. Se puede buscar una forma de mezclar las partes en conflicto... o se puede reescribir la sección en conflicto desde 0 (y esperemos que haya un muy buen conjunto de pruebas para verificar que no se está rompiendo nada).... o se puede rendir, cancelar la operación de mezcla y esperar un nuevo día con un cielo más azul y más claro para intentar la operación de nuevo.
Dada la cantidad de tiempo que toma desarrollar las habilidades para ser un mezclador eficiente y viendo el poco material que hay disponible para explicar como resolver conflictos, decidí hacer lo propio y me senté a escribir esta guía básica para ayudar a las personas a manejarlos.
Espero que cuando hayan terminado la lectura se sientas más tranquilos y cómodos a la hora de enfrentar conflictos.
Copyright 2020 Edmundo Carmona Antoranz