Ya seas un experto o un recién llegado en el uso de git, de vez en cuando se cometen errores que tienen fácil solución. Veamos las soluciones a 6 errores comunes cuando usamos git.
Cuando estamos usando git a veces, ya sea porque estamos despistados, por que no sabemos bien qué estamos haciendo o por cualquier otro motivo simplemente cometemos errores.
Algunos son complicados de solucionar y para otros (generalmente los más comunes) la solución es sencilla… si se conoce. Estas son las soluciones a 6 de los errores más comunes que cometemos cuando estamos trabajando con git.
Este artículo es una traducción de un artículo en inglés escrito por Sam Beckham para el blog de gitlab.com publicado bajo licencia CC-by-sa. Empezamos…
1. ¡Vaya! Me equivoqué al escribir el mensaje del último commit
Después de unas cuantas horas trabajando en nuestro repositorio de git, es fácil cometer un error al escribir nuestro último commit. Menos mal que existe una solución sencilla para solucionarlo:
git commit --amend
Esto abrirá el editor que tengas configurado y te permitirá realizar cambios en el comentario del último commit. Nadie tiene que darse cuenta que has escrito hacer sin «h».
Sobre esta solución ya había escrito un artículo en mi blog, que puedes encontrar aquí.
2. ¡Vaya! Olvidé añadir un archivo al último commit
Otro error muy común al usar git es realizar un commit demasiado pronto. Has olvidado incluir un archivo, quizás lo estabas editando y olvidaste guardarlo antes, o necesitas hacer un pequeño cambio que tienes que incluir en el último commit.
Para eso --amend
vuelve a ser la opción que te ayude.
Añade ese archivo faltante o gurda los cambios del archivo que necesitas incluir y que todavía tienes en el editor y ejecuta estos comandos:
git add archivo_faltante.txt
git commit --amend
En este punto puedes tanto editar el mensaje del commit o mantener el que tenías.

3. ¡Vaya! Añadí un archivo que no quería al repositorio
¿Qué pasa si hace justo lo contrario que en el caso 2? ¿Qué pasa si hemos añadido un archivo que realmente no queríamos añadir en el commit?
Quizás un archivo que no quieres compartir, una imagen que has guardado en la carpeta equivocado… Todo tiene solución.
Si sólo lo has mandado a «stage» pero no has hecho un commit, simplemente hay que quitar de «stage» el archivo que queremos:
git reset /assets/img/archivo_a_eliminar.jpg
Si ya has realizado un commit, debes dar un paso más:
git reset --soft HEAD~1
git reset /assets/img/archivo_a_eliminar.jpg
rm /assets/img/archivo_a_eliminar.jpg
git commit
Esto revertirá el commit, eliminará el archivo (en el ejemplo una imagen) y después añadirá un nuevo commit en su lugar.
4. ¡Vaya! Hice un commit con todos esos cambios en la rama principal
Quizás estás trabajando en una nueva característica o añadiendo una opción de prueba, pero olvidaste crear una rama de pruebas y en vez de eso estás trabajando sobre la rama principal del desarrollo.
Ya has hecho un commit con un montón de archivos y ahora todas esas pruebas no definitivas están en la rama principal. Afortunadamente GitLab puede prevenir que hagas push directamente en la rama principal. Así que podemos revertir los cambios a una nueva rama con estos comandos:
git branch rama-pruevas
git reset HEAD~ --hard
git checkout rama-pruevas
Esto crea una nueva rama, después revierte los cambios de la rama principal a donde fueron tus cambios y por último cambia a la nueva rama donde estarán tus cambios previos intactos.
Pasado el susto es hora de seguir probando cosas, esta vez sí en la rama de pruebas.
5. ¡Vaya! cometí un error al poner el nombre de mi rama
Los lectores más perspicaces notarán que he cometido un error al escribir el nombre de la nueva rama que he creado en el paso anterior… es tarde y ya no sé lo que tecleo. Pero es sencillo modificarlos.
Renombramos una rama de una manera similar a como lo hacemos con un archivo con el comando mv
: moviéndolo a una nueva ubicación con el nombre correcto:
git branch -m rama-pruevas rama-pruebas
Si ya habías hecho un push de esta rama al repo remoto, hay un par de pasos extra que necesitas dar. Necesitamos borrar la rama vieja del repositorio remoto y hacer un push con la nueva rama, así:
git push origin --delete rama-pruevas
git push origin rama-pruebas
6. ¡Vaya! lo hice de nuevo
Este comando es para cuando todo ha salido mal. Cuando has copiado/pegado muchas «soluciones» de sitios como Stack Overflow y tu repositorio tiene peor pinta que cuando empezaste a probar soluciones de aquí y de allí, a todos nos ha pasado.
git reflog
muestra una lista de cosas que has hecho. Después permite a git hacer mágicamente un viaje en el tiempo hasta un punto en el pasado. Hay que comentar que este es el último recurso y no debería ser utilizado a la ligera. Para ver esa lista ejecuta el comando:
git reflog
Cada paso que dimos, cada cambio que hicimos, git estaba atento. Puede darnos una lista similar a esta:
3ff8691 (HEAD -> feature-branch) HEAD@{0}: Branch: renamed refs/heads/future-brunch to refs/heads/feature-branch
3ff8691 (HEAD -> feature-branch) HEAD@{2}: checkout: moving from master to future-brunch
2b7e508 (master) HEAD@{3}: reset: moving to HEAD~
3ff8691 (HEAD -> feature-branch) HEAD@{4}: commit: Adds the client logo
2b7e508 (master) HEAD@{5}: reset: moving to HEAD~1
37a632d HEAD@{6}: commit: Adds the client logo to the project
2b7e508 (master) HEAD@{7}: reset: moving to HEAD
2b7e508 (master) HEAD@{8}: commit (amend): Added contributing info to the site
dfa27a2 HEAD@{9}: reset: moving to HEAD
dfa27a2 HEAD@{10}: commit (amend): Added contributing info to the site
700d0b5 HEAD@{11}: commit: Addded contributing info to the site
efba795 HEAD@{12}: commit (initial): Initial commit
Echa un vistazo a la columna más a la izquierda, esto es un índice. Si quieres volver a un punto del pasado de tu repositorio ejecuta el siguiente comando, reemplazando {index}
por el número al que quieras que vuelva todo el repositorio, por ejemplo dfa27a2
.
git reset HEAD@{dfa27a2}
También podemos recuperar un archivo o todo el repositorio a una versión anterior. Tienes ese tutorial aquí.
Puedes encontrar más artículos en mi blog sobre git pinchando aquí.
Gracias a la gente de GitLab por compartir este interesante tutorial, que espero que te haya sido útil, porque simplemente los errores ocurren, pero está bien saber cómo solucionarlos.
———————————————————————-
No se como trabajaba antes de git, ya ni me acuerdo… 🙂
De verdad, es un software tan bueno y valioso, que dan ganas de enseñarlo a todo mundo.
Hola.
Pues em eso estamos… Tanto para enseñar como para aprender!
Gracias por la visita y por comentar!
Me ha recordado a esta otra página web http://ohshitgit.com/ con un nombre más que apropiado.
Anda que bueno!
Gracias por compartir el enlace.
Saludos
Lo unico que hago diferente es el paso 4.
Primero borro el puntero a la rama principal (o en la que me he equivocado):
Después busco el hash del commit donde estaba master:
Y creo el puntero en ese commit:
(2b7e508 es sólo un ejemplo)
Si, además, la rama está en el servidor remoto, y está configurado como remoto en mi repositorio local, es aún más fácil.
Después de borrar el puntero:
Vuelvo a hacer el track de la rama remota:
También está el problema cuanto estás trabajando en una tarea A en una rama y has hecho varios commits, y de repente tienes que trabajar en otra tarea B urgente, creando una rama nueva.
Esa rama nueva B deberia de partir de la rama principal para no ser dependiente de la rama A (al hacer push de B también harias implícitamente push de los commits de A, y si B se une “merge” a la rama principal, los commits de A también).
Pero, si con las prisas no te has dado cuenta y a la hora de revisar los commits antes de hacer push al remoto ves que lo has hecho mal, se puede hacer rebase.
Muuuchas gracias por tu aporte!
Se nota que eres un desarrollador que sabes de Git.
Saludos y gracias por comentar!
Hola y muchas gracias por el tutorial, son muy valiosas estas aportaciones. Tengo una pregunta ¿Porqué en ocasiones que se hace un pull request aparecen commits de otros pull request?¿Que es lo que se está haciendo mal?. Muchas gracias
Hola, necesito hacer un git add . Pero me dice lo siguiente: “parece que se está ejecutando otro proceso de git en este repositorio, un editor abierto por git commit, asegúrese de que todos los procesos estén terminados e intente nuevamente, si aún falla, el proceso de git puede haberse bloqueado en este repositorio antes: elimine el archivo manualmente para continuar“ por favor ayuda , soy principiante en esto.
Hola.
¿No te deja hacer un commit ni un push?
Prueba si te da más información con los comandos:
git status
git log
Tal como te dice, mueve el archivo con el conflicto a otra ubicación, y mira si te daja hacer un git add .
Y después vuelve a añadir el archivo y vuelve a ejecutarlo
Saludos.
Buenos dias como puedo recuperar un proyecto que elimine en gitlab?
Hola.
¿Borraste tu copia local del proyecto? Si es así y todavía existe en GitLab, vuelve a clonarlo.
¿Borraste el proyecto en Gitab? Si te queda la copia local, ahí la tienes. Si tampoco tienes esa copia, ¿alguien más tiene una copia clonada del proyecto? Si es así, que te la pase.
Si no hay copia local, ni copia en Gitlab, no hay solución…
Saludos.
Hola Víctor soy nuevo en git, tengo las siguientes preguntas:
Si restauro mi repo maestro a cierto punto de la historia, perderé las ramas creadas después de ese punto?
Por que si creo una nueva rama, guardo mis cambios y los empujo al remoto, cuando creo un pull request de esto, me agrega mas commits de los que hice? como puedo detectar si en algún punto de la historia de mi master local hice algo mal
Hola!
No, al volver atrás no perderás las modificaciones ni ramas que hayas creado. Sólo irá atrás en la rama en la que regreses a un punto.
Ten en cuenta que entra en el modo «detached HEAD» por lo que podrás hacer cosas, y probar, pero ten cuidado de no perderlos. Tendrás que crear una rama en ese punto, etc.
Más info en este enlace:
https://stackshare.io/cloudbees/git-detached-head-what-this-means-and-how-to-recover
Saludos!!