En este video, vamos a aprender a resolver conflictos en Git. Cuando varios desarrolladores comparten archivos, es normal que se presenten situaciones en las que se realicen cambios de forma simultánea sobre el mismo archivo. Si no se utiliza un sistema de control de versiones, pueden sobreescribir los cambios de unos con los cambios de otros. Veamos un ejemplo, en este caso el desarrollador "uno" y el desarrollador "dos" comparten los archivos de un proyecto y los dos realizan cambios simultáneos sobre el mismo archivo. Supongamos que el desarrollador "uno" termina sus modificaciones primero y actualizan espacio compartido. Más adelante, el desarrollador "dos" termina sus modificaciones y también actualiza el espacio compartido. ¿Qué pasó con los cambios del desarrollador uno? Se perdieron. Veamos ahora qué sucede en esta misma situación cuando usamos Git. En este caso, los desarrolladores comparten un repositorio remoto y sus repositorios locales se encuentran sincronizados con el repositorio remoto. Los dos desarrolladores realizan cambios sobre el mismo archivo en sus repositorios locales. El desarrollador "uno" actualiza el repositorio remoto utilizando el comando "Push". Por ahora no tenemos ningún problema, porque la versión sobre la que hizo el cambio en su repositorio local es la misma versión que se encuentran en el repositorio remoto. Ahora, el desarrollador "dos" intenta actualizar el repositorio remoto con su cambio. Notemos que la versión sobre la que hizo su cambio en su repositorio local es diferente a la versión que se encuentra en el repositorio remoto, es decir, la versión que está en el repositorio remoto tiene cambios que el desarrollador "dos" no tiene en su copia local. En esta situación, el repositorio remoto no acepta la actualización e informa que existe un conflicto. De esta manera se evita que se sobreescriban los cambios que ya habÃa realizado el desarrollador "uno". Para hacer "Push" de sus cambios, el desarrollador "dos" debe primero actualizar el repositorio local con el repositorio remoto utilizando el comando "Pull". Git identifica que en la copia local hay cambios y no los borra, sino que mezcla los cambios que vienen del repositorio remoto con los cambios que hay en la copia local. Si al mezclarse presentan conflictos, es decir, que hay cambios que el desarrollador "dos" hizo sobre las mismas lÃneas donde el desarrollador "uno" hizo cambios, Git deja el archivo señalando el conflicto y el desarrollador "dos" debe resolverlo para decidir que queda. Cuando ya ha resuelto todos los conflictos, hace "Commit" al repositorio local y luego puede hacer "Push" al repositorio remoto. De esta forma se evitan que los cambios del desarrollador "uno" sean sobre escritos por el desarrollador "dos". Realicemos un ejemplo simple, supongamos que dos desarrolladores cambian al tiempo el archivo "readme.txt" de un proyecto. Vamos a realizar cambios en lugares diferentes del mismo archivo y luego realizaremos modificaciones sobre la mismas lineas. Verifiquemos primero que estamos actualizados con el repositorio remoto. El comando "git status" con la opción "Remote" nos sirve para eso. Vemos que el desarrollador "uno" está actualizado y que el desarrollador dos también está actualizado. El archivo "readme.txt" está igual en los dos repositorios locales y en el repositorio remoto. Como vemos, contiene solo dos lineas. El desarrollador "uno" cambia la lÃnea uno agregando la palabra "aplicación". Por su parte, el desarrollador "dos" agrega al final una palabra, la palabra "instalación". En este momento, las tres versiones las locales y la del repositorio remoto son diferentes. Si el desarrollador "uno" verifica su estado con respecto al repositorio remoto usando "git status remote", puede ver que su repositorio local está un "Commit" más adelante que el repositorio remoto. El desarrollador "uno" hace "Push" al repositorio remoto, este queda actualizado con los cambios del desarrollador "uno". Ahora, el desarrollador "dos" hace "Push", pero este "Push" es rechazado porque la versión del repositorio remoto ha sido modificada y ya no coincide con la versión sobre la cual el desarrollador dos hizo el campo. Y él nos informa que se generó un error al hacer el "Push" y además nos sugiere integrar primero los cambios del repositorio remoto con el repositorio local usando "Pull" y luego hacer un "Push". Al realizar el "Pull", Git identifica que el archivo del repositorio local ha tenido cambios. Para no perder estos cambios lo que hace es mezclar los dos archivos el que viene del repositorio remoto, con el archivo que está en el repositorio local y nos informa que los dos archivos se mezclaron de forma automática. En este caso, se pudo mezclar sin problemas porque los cambios se hicieron en lugares diferentes del archivo. Como la mezcla es exitosa, Git genera un nuevo "Commit" con estos cambios en el repositorio local. Al realizar el "Push" ya no es rechazado. Y el repositorio remoto queda actualizado con los cambios de los dos desarrolladores. Observemos que el desarrollador "uno" debe realizar un "Pull" para actualizar su repositorio local. Veamos qué pasa cuando el desarrollador "uno" y el desarrollador "dos" cambian la misma parte en un mismo archivo en sus repositorios locales. Como en este caso que los dos desarrolladores cambiaron la palabra "colaboradores" por otra. Si el desarrollador "uno" hace el "Push" de su cambio primero, este ocurre sin inconvenientes. Al hacer "Push" al desarrollador "dos", como ya sabemos, es rechazado. Y debe hacer "Pull" para actualizar su repositorio local con los cambios que no tiene el repositorio remoto. Sin embargo, ahora nos informa que no puede hacer la mezcla de forma automática y que hay un conflicto. Git reemplaza el archivo en el espacio local con la mezcla los dos archivos, incluyendo las partes en conflicto. Cada conflicto se marca entre los signos menor, menor, menor y mayor, mayor, mayor y con igual, igual se separa lo que hay en el repositorio local de lo que hay en el repositorio remoto. En este caso, en el espacio local tenemos la lÃnea "desarrolladores" y en el repositorio remoto la lÃnea "equipo". Podemos usar el "status" para ver el estado del repositorio local. Lo primero que nos informa es que el repositorio local y el repositorio remoto tienen, cada uno, un "Commit" adicional. Luego, nos indica que tenemos una mezcla con conflictos. Para resolver el conflicto, el desarrollador "dos" decide conservar el tÃtulo de "equipo" propuesto por el desarrollador "uno". Para esto, elimina las marcas que insertó Git para señalar el conflicto y deja el archivo como se requiere. Ahora, debemos actualizar el repositorio local. Podemos usar "git Commit" con las opciones "menos a" y "menos m". La opción "menos a" sirve para que antes de hacer el "Commit" pase todos los archivos del repositorio que han sido modificados a la zona de preparación y asà podemos saltarnos hacer el comando "At". Es importante, cuando hacemos "Commit" de mezclas, que el mensaje sea explÃcito al respecto. Al hacer "Commit" nos informa que el repositorio local está dos "Commits" adelante con respecto al repositorio remoto. Solo nos falta enviar los cambios del repositorio remoto con el comando "Push" que ya no es rechazado. Resumamos. Cuando se realizan cambios simultáneos por dos desarrolladores en un archivo, se pueden presentar conflictos. Si los cambios no se interceptan, es decir, son independientes entre ellos, Git nos ayuda a mezclar los cambios y a dejarlos en el repositorio. Si los cambios interceptan, Git nos ayuda a mezclar los cambios y nos señala los conflictos. El desarrollador al que se le presenta el conflicto debe resolverlo y enviar los cambios al repositorio local y luego al repositorio remoto.
