El comando Git reset en Git


Lección 28 / 53

El comando Git reset en Git

Git Guía Git Guía Git español

De manera similar al anterior, el comando git reset en Git permite deshacer los commit de un repository, pero lo hace destructivamente. En particular, git reset puede operar en el historial de los commit, por lo tanto, permite modificar el historial de un branch específico. Es un comando que debes usar con cuidado si no quieres perder parte de tu trabajo.

De hecho, el comando se describe oficialmente como git-reset: Reset current HEAD to the specified state y, según el uso real, permite el "reset" de diferentes situaciones. De hecho, además del historial de los commits, también afecta al staging area y a la working directory dependiendo del modo en que se realice (soft, mixed o hard).

La versión extendida del comando es la siguiente:

git reset [--soft|--mixed|--hard] [<REFERENCE>]

Si no se indica, el modo mixto se usa por defecto y el HEAD actual se usa como referencia.

Los tres modos se diferencian de la siguiente manera:

  • soft - no toca los cambios en staging area, no toca los cambios en la working directory
  • mixed - quita los cambios de la staging aree y los lleva a la working directory, no toca ningún otro cambio en la working directory
  • hard - elimina los cambios en staging area, elimina los cambios en la working directory (es decir, elimina para siempre cualquier cambio no guardado como commit)
     
$ git log --oneline
* 517c168 (HEAD -> master) Revert "improve performance on first feature"
* 1e6ed4a add second feature
* cc7f96f improve performance on first feature
* 1e1bf33 add first feature
* f6a76e4 initialize project
$ git add second.py
$ git status --short
M first.py
M  second.py

Si suponemos que nuestro repository tiene una cierta historia y tenemos algunos cambios en proceso, tanto en la working directory como en la staging area, y que no estamos en un estado “detached”, indicando solo la modalidad tendremos como resultado que:

  • soft -> prácticamente sin cambios
  • mixed -> limpia la staging area
  • hard -> elimina todos los cambios y vuelve alineados con HEAD

Sin embargo, si indicásemos como referencia para restablecer uno de los commit:

$ git reset --hard cc7f96f
HEAD is now at cc7f96f improve performance on first feature
$ git log --oneline
cc7f96f (HEAD -> master) improve performance on first feature
1e1bf33 add first feature
f6a76e4 initialize project
$ git status --short
?? second.py

En este caso, todos los commits posteriores al indicado en el comando git reset han sido eliminados del historial local del branch. El archivo second.py ha vuelto a ser untracked, ya que no existía en esa versión del proyecto. Básicamente, hemos pasado de esta situación:

[a]<--[b]<--[c]<--[d]<--[e]::{main}
                            |
                            HEAD

A una situación en la que los commit posteriores a la que se restablece ya no forman parte del branch:

                   [d]<--[e]

[a]<--[b]<--[c]::{main}
                |
                HEAD

¿Para qué puede ser útil el comando git reset en Git?
En general, es útil para revertir cambios locales que nunca se publicaron en un origen compartido. Eliminar un commit de un repository en el que otros desarrolladores web pueden haber seguido desarrollando crea serios problemas para la colaboración. Los posibles casos de uso pueden ser, por tanto, los siguientes:

  • git reset --hard: elimina cualquiera de sus propios cambios y devuelve la working directory en sync con el último commit;
  • git reset: “limpia” la staging area, manteniendo cualquier diferencia con el último commit en la working directory;
  • git reset <FILE>: igual que arriba, pero solo para un archivo específico y no para todos los cambios;
  • git reset --hard <COMMIT>: en el caso de que nos demos cuenta de que a partir de un determinado commit en adelante, y solo si estos commit han permanecido en su clon local, el trabajo se descarta por completo sin dudarlo, lleva el proyecto de vuelta a este "buen" commit, desechando el resto.
Guía Git en español 1 ¿Qué es Git? 2 Nacimiento de Git 3 Principales características de Git 4 Línea de comando UI en Git 5 Cómo instalar Git 6 5 comandos Git para desarrolladores individuales 7 5 comandos Git para desarrollar en colaboración 8 Repository en Git 9 Commit en Git 10 Working Copy en Git 11 Staging Area en Git 12 Branch en Git 13 Remote en Git 14 Inicializar un nuevo repository con git init 15 Crear una copia de un repository remoto en Git con git clone 16 Configurar las opciones de Git con git config 17 El comando Git add en Git 18 El comando Git commit en Git 19 El comando Git diff en Git 20 El comando Git stash en Git 21 .gitignore : los archivos ignored en Git 22 El comando Git status en Git 23 El comando Git log en Git 24 El comando Git tag en Git 25 El comando Git blame en Git 26 El comando Git checkout en Git 27 El comando Git revert en Git 28 El comando Git reset en Git 29 El comando Git rm en Git 30 La opción Git commit –amend en Git 31 Git rebase –interactive en Git 32 Atajos para comandos frecuentes en Git 33 Repository compartido en Git 34 El modelo Fork & pull 35 El comando Git remote en Git 36 Los principales repository remote de Git: Github, Gitlab y Bitbucket 37 El comando Git fetch en Git 38 El comando Git push en Git 39 El comando Git pull en Git 40 El comando Git branch en Git 41 El comando Git checkout en Git 42 El comando Git merge en Git 43 Resolver un merge conflict en Git 44 Entender mejor el contenido de los commit durante un conflicto de merge en Git 45 Workflow Git centralizado 46 Workflow Git feature branching 47 Workflow Git trunk-based 48 Enfoque “forking” en Git 49 Gitflow en Git 50 Mensajes de commit en Git 51 Tagging & Versioning en Git 52 La opción merge en Git 53 La opción rebase en Git

© 2022 Aulab. Todos los derechos reservados • P.IVA: IT07647440721 • Política de privacidad