Hasta ahora hemos tratado el escenario ideal: escribes código, haces commits, creas Pull Request. Pero en la vida real muchas cosas suelen ir mal: puedes cometer un error en el código, hacer un commit con un mensaje incorrecto o simplemente darte cuenta de que ibas en la dirección equivocada. En esta lección veremos cómo resolver los problemas más comunes.
1. Rollback — deshacer cambios antes del commit
Escenario: has modificado un archivo, pero te das cuenta de que todos tus cambios son incorrectos y quieres volver rápidamente el archivo al estado en el que estaba después del último commit.
Usa la función Rollback:
- Abre la pestaña
Commit. - Encuentra en la lista el archivo modificado que quieres "revertir".
- Haz clic derecho sobre él y selecciona
Rollback.
El IDE te advertirá que los cambios se perderán. Acepta, y el archivo volverá instantáneamente a su última versión guardada en Git. Es la forma más simple y segura de cancelar cambios locales.
2. Reset — eliminar commits locales
Escenario: hiciste uno o varios commits, pero aún no hiciste push. Te das cuenta de que esos commits son erróneos y quieres borrarlos por completo, como si nunca hubieran existido.
Usa la función Reset:
- Abre la pestaña
Git -> Logpara ver el historial de commits. - Encuentra el último commit "bueno" en el que quieres quedarte (el que está antes de los erróneos).
- Haz clic derecho sobre él y selecciona
Reset Current Branch to Here....
En la ventana que se abre te pedirán elegir el modo de reset. El más radical es Hard.
¡Atención! El modo Hard borra de forma irreversible todos los commits posteriores al seleccionado, así como todos los cambios en el código que estaban en esos commits. Úsalo con mucha precaución y solo para esos commits que nadie ha visto aún (es decir, que no se han enviado a GitHub).
3. ¿Qué hacer después del Push?
Escenario: hiciste push, y solo después notaste un error en él.
En cuanto el commit llega al servidor remoto, pasa a formar parte de la historia compartida del proyecto. Intentar reescribir esa historia puede crear enormes problemas para tus compañeros. Imagínate que ellos ya descargaron tus cambios y empezaron a trabajar sobre ellos.
La solución correcta y segura:
Simplemente haz un nuevo commit que corrija el error y envíalo. Es una práctica totalmente normal. Así la historia sigue siendo honesta y comprensible para todos.
4. Mirar al pasado: trabajo avanzado con el log
Ya conocemos la pestaña Git -> Log, pero no es solo una lista de commits, sino una herramienta potente para investigar.
- Hash del commit (Commit Hash): seguramente has visto en el log una línea de letras y números, por ejemplo
a1b2c3d. Ese hash es único y permite referirse con precisión a cualquier punto en la historia del proyecto. Rara vez tendrás que usarlo manualmente, pero es importante saber que es el identificador único de cada "snapshot" de tu código.![]()
- Puedes filtrar el historial por rama, autor, fecha o incluso por palabra en el mensaje del commit. Esto ayuda a encontrar rápidamente quién y cuándo trabajó en cierta parte de la funcionalidad.
- ¿Quieres encontrar el commit en el que se añadió o eliminó una línea específica de código? En la ventana
Loghay un campo de búsqueda que no solo busca en los mensajes, sino también en el contenido de los cambios. - Haz clic derecho en las márgenes del editor de código y selecciona
Annotate with Git Blame. El IDE mostrará al lado de cada línea quién la modificó por última vez y en qué commit. Es increíblemente útil para entender por qué el código está escrito de cierta manera.
5. Zona peligrosa: Force Push
Hemos establecido que modificar commits ya enviados es una mala idea. Pero ¿qué pasa si aun así cambiaste tu historia local (por ejemplo, con Reset) y ahora difiere de la historia en el servidor? Al intentar hacer un push normal, Git dará un error, protegiendo la historia compartida de ser sobrescrita.
Para esos casos existe la opción — force push (envío forzado). Este comando le dice al servidor: "Olvídate de lo que tenías. Mi versión local de la historia es la correcta. Reemplaza tu historia por la mía".
¡ADVERTENCIA! En el 99% de los casos usar force push en proyectos de equipo es una catástrofe. Puede borrar de forma irreversible commits que tus compañeros ya descargaron y sobre los que están trabajando. Es equivalente a arrancar páginas de un libro compartido y pegar las tuyas.
Cuándo está terminantemente PROHIBIDO usar force push:
- En cualquier rama compartida:
main,develop,master. Nunca. - En cualquier rama en la que trabaje alguien más además de ti.
El único escenario aceptable:
Estás trabajando en tu feature-branch personal, que nadie más ha visto ni usado. Hiciste varios commits "sucios", los enviaste al servidor y luego decidiste "limpiarlos" con Reset. En ese caso puedes hacer force push para actualizar tu rama en el servidor antes de crear el Pull Request.
En el IDE esta opción suele estar escondida detrás del botón Push. Los desarrolladores del IDE lo hicieron a propósito para que no la pulses por accidente.
Si no estás 100% seguro de lo que haces — nunca uses force push. Es más seguro crear un nuevo commit con las correcciones.
6. Actualizar el proyecto
Siempre pulsa Update Project en la rama main antes de comenzar a trabajar en una nueva tarea. Esto te protegerá de muchos futuros conflictos de merge y garantizará que empiezas a trabajar con la versión más actual del código.
GO TO FULL VERSION