Quantcast
Channel: Amin Espinoza
Viewing all articles
Browse latest Browse all 116

Como evitar un conflicto de versiones al unificar un proyecto con VS Code

$
0
0

El escenario es fácil y mucho más común de lo que quisieramos admitir. Estás terminando tus cambios y no hiciste un pull para solicitar los últimos cambios o simplemente mientras tú estabas trabajando alguien más lo hizo. Al querer crear tu Pull Request notarás que te aparece un problema para fusionar. En mi caso usaré Github únicamente porque fue lo primero que me llegó a la mente pero básicamente lo puedes hacer de esta manera en cualquier repositorio basado en Git.

En el siguiente diagrama podemos ver qué es lo que está sucediendo.

Ambas ramas obtuvieron de main el contenido y la rama aminespinoza-patch-1 hizo un merge justo en el mismo documento y líneas que la rama aminespinoza, el problema es que cuando la rama quiere crear un Pull Request entonces aparece el temido mensaje.

Y aquí es donde la cosa se pone interesante porque todo tu trabajo se queda detenido hasta resolver este problema, con toda la calma del mundo debes abrir una terminal y escribir el comando git branch para saber en qué rama te encuentras, te recomiendo hacerlo desde VS Code para que sus herramientas integradas te hagan la vida más fácil.

El conflicto es con la rama aminespinoza-patch-1 así que primero pasa a esa rama con el comando git checkout.

Ya con la nueva rama, puedes ejecutar el comando git pull desde la rama recién tomada para que el conflicto se traslade a tu repo local..

Ahora, ya con VS Code abierto, el comando que sacará todos los conflictos a la vista será el comando git merge.

Con esto VS Code te mostrará los conflictos. Algo como esta pantalla.

Las opciones que tienes son cuatro, cada una naturalmente tiene su escenario.

  • Aceptar el cambio actual: Significa que los cambios hechos por la rama prevalecerán sobre los cambios anteriores
  • Aceptar el cambio venidero: Significa que los cambios hechos por la rama principal prevalecerán sobre tus cambios.
  • Aceptar ambos cambios: La verdad es que yo nunca he elegido esta opción, si hay un conflicto creo que es muy difícil que ambos elementos puedan prevalecer, como sea, la opción está ahí.
  • Compare both changes: Se refiere a un nuevo despliegue de pantallas para poder comparar los cambios.

Para efectos de este ejercicio, lo que sigue elegir la primera opción, aceptar los cambios actuales y depsués de ello, seguir con un nuevo commit.

Después del commit y de hacer un push el conflicto desaparecerá en el Pull Request de manera automática justo después de tu último cambio enviado.

¡Listo! Algo rápido y práctico para poder solucionar lo que puede ser un conflicto grande pero no requiere más complejidad.


Viewing all articles
Browse latest Browse all 116

Trending Articles