El comando Git reset en Git

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.