5 Comandos de Git para Salvarte la Vida (y tu empleo)
Todos hemos estado allí: sudor frío recorriendo la espalda tras ejecutar un git reset --hard en la rama equivocada, o ese genuino terror al darte cuenta de que accidentalmente hiciste commit a un archivo .env repleto de credenciales de producción hacia el repositorio público de tu empresa.
Git es una de las herramientas tecnológicas mejor diseñadas de la historia del software. Paradójicamente, está construido con tal grado de robustez que es físicamente difícil eliminar código para siempre en Git si sabes exactamente dónde (y con qué comando) buscar.
Apaga el estrés y guarda este listado de emergencia; aquí tienes los 5 comandos que te devolverán el pulso.
1. La máquina del tiempo definitiva: git reflog
Cuando decimos que es casi imposible perder código en Git, es gracias al Reflog. A diferencia del historial normal (git log) que solo muestra los commits que terminaron exitosamente en tu rama actual, el Reflog es una bitácora secreta local que anota, literalmente, cada acción que has realizado afectando la punta del árbol (HEAD), incluso aquellas acciones destructivas.
¿Borraste una rama por accidente? ¿Hiciste un rebase desastroso que sobreescribió tu progreso de toda la semana?
git reflog
Verás una lista con identificadores extraños como HEAD@{0}, HEAD@{1}, seguida de la acción (“commit”, “checkout”, “reset”, “rebase”). Cuando identifiques visualmente el estado “seguro” o “saludable” justo antes de cometer tu error catastrófico, viaja en el tiempo hacia esa fotografía forzando un reseteo duro apuntando hacia el identificador:
# ¡Rescate exitoso! Te regresa exactamente a como estaba todo en ese instante
git reset --hard HEAD@{3}
TIP
Por defecto, Git solo permite viajar en el tiempo dentro del reflog y retiene esos “fantasmas” durante 30 días. Tras ese plazo, por optimización de espacio el sistema de basura local (git gc) los purgará. ¡Aprovéchalo mientras puedas!
2. El corrector de olvidos inofensivo: git commit --amend
Acabas de hacer un commit muy bonito ("feat: Integración con la pasarela de pagos")… y cinco segundos después notas que en tu barra lateral tienes un archivo crucial sin guardar que olvidaste añadir (utils.js).
Muchos perfiles Junior añadirían el archivo haciendo otro bochornoso commit llamado “ahora sí el archivo”. Los perfiles senior usan --amend para parchar silenciosamente el error como si nunca hubiese ocurrido, fusionándolo limpiamente dentro del último eslabón de la cadena de historiales.
# 1. Empaqueta el archivo olvidado en la caja (Staging area)
git add utils.js
# 2. Fusiónalo con tu commit anterior (y mantén el mismo mensaje original)
git commit --amend --no-edit
WARNING
Jamás utilices --amend si tu commit original ya ha sido arrojado (git push) al servidor público remoto (como GitHub o GitLab). Reescribir la historia localmente está perfecto, pero si reescribes historia que otros compañeros ya descargaron, les romperás sus entornos locales estrepitosamente.
3. El salvavidas temporal: git stash
Estás a la mitad de programar un bloque de lógica muy compleja. Tienes 15 archivos modificados llenos de console.logs rotos, y en eso tu Tech Lead te llama con urgencia: “¡El servidor está caído, pásate a la rama hotfix/login de inmediato y ayúdame a encontrar el bug de producción!”
No puedes hacer commit de código roto o a medias, pero si cambias de rama usando git checkout Git te arrojará un error bloqueante exigiendo que lidies con los cambios pendientes. La caja de seguridad de Git para esto se llama Stash.
El stash toma temporalmente todos tus archivos sucios del escritorio y los guarda en un maletín hermético dejándote tu rama de trabajo impecable, permitiéndote navegar rápidamente hacia tu rama de rescate.
# Guarda temporalmente tu trabajo, pero sin necesidad de hacer commit
git stash save "Trabajando en pasarela de pagos, a medio terminar"
Luego de haber salvado el día y regresar a tu rama original al finalizar, sencillamente desempaquetas ese maletín sobre tu mesa y continúas con tu café y auriculares en el exacto punto donde lo dejaste:
# Recupera tus cambios del primer puesto del maletín y elimínalos del stash
git stash pop
4. El botón “deshacer”: git restore --staged <archivo>
Se trata de un pánico recurrente al teclear el perezoso e indiscriminado git add . en la consola. Ves que el contador de archivos empacados y listos para el commit repentinamente incluye un documento .env saturado de API_KEYS confidenciales de la empresa.
Para sacar el archivo de la caja (sacarlo del Staging Area) sin perder el progreso que has escrito en él, olvídate del anticuado e impreciso git rm --cached. El enfoque declarativamente amigable y recomendando en Git moderno es a través de restore:
git restore --staged .env
Ejecutar esta línea descenderá instantáneamente el archivo de [Staged Changes] a [Changes]. Tu commit estará a salvo y protegido contra fugas de información masiva.
5. El arrepentimiento inmediato: git reset --soft HEAD~1
Hay días donde por velocidad cometes errores de dedo fatales en el mensaje de tu tag o el commit (git commit -m "correjinod un bog"), o descubres un bug crítico un segundo después de oprimir “Enter”. Tienes la abrumadora necesidad de destruir ese commit.
El reflejo novato es buscar en internet y utilizar el indiscriminado destructor de mundos git reset --hard HEAD~1, lo cual ciertamente destruirá ese commit, pero también pulverizará borrará irrevocablemente toda tu hora incesante codificando el bloque.
Lo que en realidad querías era destruir la envoltura, pero conservar intacto el regalo de adentro. El parámetro clave es hacerlo de manera “blanda”:
git reset --soft HEAD~1
Este comando mágico destruye ese último eslabón de la gráfica visual del historial, pero deja los 15 archivos con todos sus renglones en verde reposando serenamente en tu mesa local (Staging area), dándote el control de modificar lo que consideres pertinente para envolver la caja por segunda vez tranquilamente.