Hasta ahora hemos visto un escenario ideal: escribes código, haces commits y creas un Pull Request. Pero en la vida real a menudo algo sale mal: puedes cometer un error en el código, hacer un commit con un mensaje incorrecto o simplemente darte cuenta de que no ibas en la dirección correcta. 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 has dado cuenta de que todos tus cambios son incorrectos y quieres devolver rápidamente el archivo al estado en el que estaba tras el último commit.
Usa la función Rollback:
- Abre la pestaña
Commit. - Encuentra en la lista el archivo modificado que quieres «revertir».
- Haz clic sobre él con el botón derecho del ratón y elige
Rollback.
La IDE te advertirá de que se perderán los cambios. Acepta, y el archivo volverá al instante a su versión guardada por última vez en Git. Es la forma más sencilla y segura de deshacer cambios locales.
2. Reset — eliminación de commits locales
Escenario: has hecho uno o varios commits, pero aún no has hecho push. Te diste cuenta de que esos commits son erróneos y quieres eliminarlos 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 quedar (el que fue antes de los erróneos).
- Haz clic sobre él con el botón derecho del ratón y elige
Reset Current Branch to Here....
En la ventana que se abre se te pedirá elegir el modo de reset. El más drástico — Hard.
¡Atención! El modo Hard elimina irreversiblemente todos los commits posteriores al seleccionado, así como todos los cambios de código que había en esos commits. Úsalo con mucha precaución y solo para commits que nadie más haya visto (los que no se han enviado a GitHub).
3. ¿Qué hacer después de Push?
Escenario: has hecho push, y solo después detectaste un error en él.
En cuanto un commit llega al servidor remoto, pasa a formar parte del historial compartido del proyecto. Intentar reescribir ese historial puede crear enormes problemas a tus compañeros. Imagina que ya se han descargado tus cambios y han empezado su trabajo basándose en ellos.
Solución correcta y segura:
Simplemente haz un nuevo commit que corrija el error y envíalo. Es una práctica absolutamente normal. Así, el historial se mantiene honesto y comprensible para todos.
4. Echar la vista atrás: trabajo avanzado con el log
Ya conocemos la pestaña Git -> Log, pero no es solo una lista de commits, sino una potente herramienta de investigación.
- Hash del commit (Commit Hash): seguro que has visto en el log una cadena de letras y números, por ejemplo
a1b2c3d. Este hash es único; permite referirse con exactitud a cualquier punto del historial del proyecto. Rara vez tendrás que usarlo manualmente, pero es importante saber que es el identificador único de cada «instantánea» de tu código.![]()
- Puedes filtrar el historial por rama, autor, fecha o incluso por una palabra en el mensaje del commit. Esto ayuda a encontrar rápidamente quién y cuándo trabajó en una parte concreta de la funcionalidad.
- ¿Quieres encontrar el commit en el que se añadió o eliminó una línea de código concreta? En la ventana
Loghay un campo de búsqueda que busca no solo por mensajes, sino también por el contenido de los cambios en sí. - Haz clic con el botón derecho en los márgenes del editor de código y elige
Annotate with Git Blame. La IDE mostrará frente a cada línea quién y en qué commit la cambió por última vez. Es increíblemente útil para entender por qué el código está escrito así.
5. Zona de peligro: Force Push
Hemos dejado claro que cambiar commits ya enviados es una mala idea. Pero, ¿y si aun así modificaste tu historial local (por ejemplo, con Reset) y ahora no coincide con el historial del servidor? Al intentar hacer un push normal, Git dará un error para proteger el historial compartido de sobrescrituras.
Para estos casos existe la opción — force push (envío forzado). Este comando le dice al servidor: «Olvida todo lo que tenías. Mi versión local del historial — la única válida. Sustituye tu historial por el mío».
¡ATENCIÓN! 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 han descargado y sobre los que están trabajando. Equivale a arrancar páginas de un libro de biblioteca 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 esté trabajando alguien más aparte de ti.
Único caso permitido:
Estás trabajando en tu rama personal de funcionalidad (feature), que aún nadie ha visto ni utilizado. Hiciste varios commits «sucios», los enviaste al servidor y luego decidiste «ponerlos en orden» con Reset. En ese caso, puedes hacer force push para actualizar tu rama en el servidor antes de crear el Pull Request.
En la IDE esta opción suele estar oculta tras el botón Push. Los desarrolladores de la IDE lo hicieron deliberadamente para que no la pulses por accidente.
Si no estás seguro al 100 % de lo que haces, no uses nunca force push. Es más seguro crear un nuevo commit con las correcciones.
6. Actualización del proyecto
Pulsa siempre Update Project en la rama main antes de empezar a trabajar en una tarea nueva. Esto te ahorrará muchos futuros conflictos de merge y garantiza que empiezas a trabajar con la versión más actual del código.
GO TO FULL VERSION