Git en tiempos de problemas

Ó cómo corregir revertir un problema causado en la base del código.

Actualmente es posible implementar buenas prácticas mientras codificamos soluciones. Y debemos hacerlo, nunca sabes cuando tu computadora decidirá dejar de funcionar, ó el disco duro hacer una implosión dejándonos al borde de la locura.

Una buena práctica para cualquier usuario de computadora en cualquier nivel de experiencia (desde el más básico en adelante), la más sencilla, es hacer respaldos periódicamente. Es la más básica de todas las rutinas que debemos implementar. Más temprano que tarde, te resolverá un problema crítico.

Otra de las prácticas recientes es respaldar tu progreso a la nube. Esta opción es extredamente útil pues nos ofrece la flexbilidad de operar en diferentes equipos, casi siempre sin notas extras.

Profesionamente debemos usar un repositorio central de versiones de código fuente (VCS). Yo uso git.

Git es la mejor herramienta básica para un programador moderno — aunque su uso debería extenderse a cualquier usuario. Usandólo correctamente y en el momento apropiado, amigo, es un salvavidas.

 

Tiempos modernos, viejos problemas.

Resulta que crear una aplicación en Visual Studio (VS) 2015, después recompilarla en VS2017 debería algo trivial en tiempos modernos. De hecho lo es. Pero el diablo está en los detalles dicen.

Permíteme explicarme.

Tenemos una misma aplicación, compilada originalmente para .NET 4.5.1 en VS2015. Misma que el VS2017 sugirió actualizar .NET 4.6.1 y degradada a 4.5.2 en la misma herramienta. Porqué VS2017 ha sugerido esa versión y no permite cambiar a 4.5.1? de algún modo, 4.5.1 no está más disponible pues era una versión de tránsito, por ningún modo permitió compilar a dicha versión. Entonces cambié a compilar a 4.5.2. Esto debe ser considerado pues el servidor destino sigue teniendo la misma versión de .NET, sin cambios aún.

Entonces, el problema viene cuando quieres publicar ése código (compilado a .NET 4.5.2 por el VS2017) en el ambiente final. Las aplicaciones ASP.NET MVC y ASP.NET WebAPI deben ser recompiladas por el IIS la primera vez que se cargan. Al hacer esto, quién sabe que carajos hace el compilador Roslyn que simplemente no permite compilar en IIS, y tenemos los mismos viejos problemas de hace años: “no sabemos porqué, pero falló en Microsoft”.

Con las herramientas de Microsoft, heredas problemas al migrar proyectos usando diferentes versiones de VS. Mismos viejos problemas.

 

Git y el poder regresar en el tiempo.

Una de las características de Git es poder regresar a versiones pasadas (commits), completamente, todo lo que contenía el repositorio.

Potencialmente pueden surgir muchas razones para querer regresar a commits anteriores. Yo identifico 2 casos básicos:

  1. Regresar para leer cómo estaba un código en el pasado, pero manteniendo la lista de commits. Esto podría hacerme regresar a “el presente” (branch master) en mi código fuente.
  2. Regresar para hacer un commit pasado el branch master. Esto significa que quieres borrar una serie commits actuales que ya no te sirven.

Para lograr esos casos existen 3 estragegias: Tags, Branchs y Commits.

Para el caso #1, bastaría con:

# Regresar al commit antes del conflicto

# esto es particularmente cuando quieres hacer un ammend del último commit
git reset --soft HEAD~1

# Pull la versión remota
git pull

# Sobre encima el nuevo commit y envíalo con un push
git add ...
git commit
git push

Otro modo sin peder los cambios sería:

# encuentra el commit antes del conflicto:

git log

# copia el commit sano, antes del conflicto (copiar el Hash del commit)

git checkout theHashYouJustCopied
git checkout -b your_new_awesome_branch

# Hasta aquí se creo un branch para el commit bueno, en caso de que no hubiése

# Seguir éste camino para mantener incluso el branch en que se detectó el problema:

git checkout the_errant_branch
git log

# Ahora mueve asegurarnos que el commit bueno (declarado en el branch creado) sea el nuevo master

git checkout your_new_awesome_branch
git cherry-pick theHashYouJustCopied

 

Finalmente, la opción nuclear. Básicamente, que es la que utilicé recientemente, sirve para mandar a la chingada, el resto de commits que no son útiles.

Referencias:

https://sethrobertson.github.io/GitFixUm/fixup.html

https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#The-Nuclear-Option:-filter-branch

El escenario para esto es que has detectado:

  1. Repositorio branch master actual no me sirve
  2. No tengo correctamente branchs ni tags creados, pero si commits
  3. Hay un commit bueno en el pasado el cual quiero hacer el master y desde ahí continuar el desarrollo
  4. Borrar la historia de commits más reciente, hasta antes del commit bueno

“Cada poder, requiere cierta responsabilidad”: hacer esto te puede acarrear muchos problemas Sí y solo Sí tus commits son públicos y otros colaboradores dependen de ellos.

Si eres un desarrollador solo, no tienes problemas en absoluto.

# utilizar el commit bueno detectado en git log
git reset --hard <last_working_commit_id>
# empujar al remote que la versión actual del master es la buena
git push --force

 

Y con esto, quedamos de regreso a donde estabámos, lo cual espero sea una versión buena código.

Suerte!

Leave a Reply

MANTENTE INFORMADO

Subscribete a mi lista de correo y recibe mis actualizaciones.

Gracias por subscribirte!

Ups! algo salió mal en el envío, intenta nuevamente.