Los comandos git reset y git rm tienen utilidades muy diferentes, pero pueden confundirse

fácilmente.

Git reset
El comando git reset es una herramienta poderosa que te permite deshacer o revertir
cambios en tu repositorio de Git. Lo puedes ejecutar de tres maneras diferentes, con las
líneas de comando --soft, --mixed y --hard.

Pero no como git checkout que nos deja ir, mirar, pasear y volver. Con git
reset volvemos al pasado sin la posibilidad de volver al futuro. Borramos la historia y la
debemos sobreescribir. No hay vuelta atrás.

Tres árboles en Git

Para entender lo anterior, recordemos que los “tres árboles” de Git son estructuras de datos
basadas en nodos y punteros que Git utiliza para hacer seguimiento a un cronograma de
ediciones, aunque no sean estructuras en forma de árbol en el sentido tradicional.

La mejor forma de entender estos mecanismos es creando un conjunto de cambios en un

repositorio y siguiéndolos a través de los tres árboles. Averigüémoslo.

$ mkdir git_reset_test
$ cd git_reset_test/
$ git init .
Initialized empty Git repository in /git_reset_test/.git/
$ touch reset_lifecycle_file
$ git add reset_lifecycle_file
$ git commit -m"initial commit"
[main (root-commit) d386d86] initial commit
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 reset_lifecycle_file
¿Cómo funciona Git Reset en tu flujo de trabajo?
git reset permite moverte entre diferentes commits para deshacer o rehacer cambios. Git
guarda todos lo nuevo del repositorio como commits, que son instantáneas del estado del
código en un momento dado y existen variaciones de este comando.

Variaciones de Git Reset

 git reset --soft: Borra el historial y los registros de Git de commits anteriores,
pero guarda los cambios en Staging para aplicar las últimas actualizaciones a un
nuevo commit.
 git reset --hard: Deshace todo, absolutamente todo. Toda la información de los
commits y del área de staging se elimina del historial.
 git reset --mixed: Borra todo, exactamente todo. Toda la información de los
commits y del área de staging se elimina del historial.
 git reset HEAD: El comando git reset saca archivos del área de staging sin
borrarlos ni realizar otras acciones. Esto impide que los últimos cambios en estos
archivos se envíen al último commit. Podemos incluirlos de nuevo en staging con
git add si cambiamos de opinión.

Ten en cuenta que, si deshaces commits en un repositorio compartido en GitHub, estarás

cambiando su historia y esto puede causar problemas de sincronización con otros
colaboradores.

¿Qué es git reset HEAD?

git reset HEAD es un comando que te permite revertir los cambios que ya habías
preparado para subir, y moverlos de vuelta a tu proyecto. Con este comando puedes
cancelar los cambios que ya habías agregado, para que puedas revisarlos, modificarlos o
deshacerlos antes de confirmarlos con un commit.

Git rm
Por otro lado, git rm es un comando que nos ayuda a eliminar archivos de Git sin eliminar
su historial del sistema de versiones. Para recuperar el archivo eliminado, necesitamos
retroceder en la historia del proyecto, recuperar el último commit y obtener la última
confirmación antes de la eliminación del archivo.

Es importante tener en cuenta que git rm no puede usarse sin evaluarlo antes. Debemos
usar uno de los flags siguientes para indicarle a Git cómo eliminar los archivos que ya no
necesitamos en la última versión del proyecto.

Variaciones de Git rm

 git rm --cached: Elimina archivos del repositorio local y del área de staging, pero
los mantiene en el disco duro. Deja de trackear el historial de cambios de estos
archivos, por lo que quedan en estado untracked.
 git rm --force: Elimina los archivos de Git y del disco duro. Git guarda todo, por
lo que podemos recuperar archivos eliminados si es necesario (empleando
comandos avanzados).

¡Al usar git rm lo que haremos será eliminar este archivo completamente de git!

¿Cuál es la diferencia entre git rm y git reset Head?

La diferencia principal entre git rm y git reset HEAD radica en que git rm elimina
archivos del repositorio y de la historia del proyecto, mientras que git reset saca los
cambios del área de preparación y los mueve del espacio de trabajo, sin afectar la historia
del repositorio.
Es importante tener en cuenta el efecto que cada comando tiene en el proyecto y usarlos
según tus necesidades y objetivos específicos.

¿Cuándo utilizar git reset en lugar de git revert?

Para reescribir la historia del repositorio y eliminar confirmaciones anteriores, se utiliza
git reset. Para deshacer cambios de confirmaciones anteriores de forma segura sin
modificar la historia del repositorio, se emplea git revert.
Resumen
Para evitar problemas en el trabajo, es valioso entender las implicaciones y riesgos de cada
comando y elegir el enfoque adecuado según las necesidades y el flujo de trabajo del
proyecto.

Con git rm eliminamos un archivo de Git, pero mantenemos su historial de cambios. Si no

queremos borrar un archivo, sino dejarlo como está y actualizarlo después, no debemos
usar este comando en este commit.

Empleando git reset HEAD, movemos los cambios de Staging a Unstaged, pero
mantenemos el archivo en el repositorio con los últimos cambios en los que hicimos
commit. Así, no perdemos nada relevante.

RESUMEN

Sabemos que tenemos tres zonas (Directorio, Staging y Repositorio)

Cuando editamos un archivo y salvamos los cambios solamente, Git detecta que hay una
modificación y esto lo vemos con el comando git status o git diff.

Cómo ocurre esto? Esto se logra porque cuando se ejecuta un commit, se genera un Path o
ruta del archivo en las tres zonas mencionadas, el archivo queda encadenado entre el
directorio y el repositorio, Git hace un tracking o rastreo por la ruta establecida para
detectar los cambios. cuando ejecutamos el comando git status o git diff, GIT los refleja en
pantalla.

Ahora bien, volvamos al punto donde solamente edité el archivo en la zona del directorio y
salvé los cambios, para introducirlo en la zona de staging debemos hacerlo con…git add
cierto?....Bien..!

Supongamos ahora que deseamos sacar de la zona staging el archivo, tenemos dos
opciones:

a) git reset head file: mueves el archivo al directorio simplemente, si ejecutas git status o git
diff observarás que GIT sigue detectando cambios en el archivo, porque la ruta o path sigue
rastreada o tracked, puedes aprovechar esto para devolver los cambios que editaste en el
archivo, recuerda que ahora esta en el directorio, ejecutando el comando git restore file,
dejarás el archivo como lo encontraste y si deseas comprobar que todo está “original” ;
ejecuta el comando git status o git diff, verás que git no detecta cambios. “git reset head
file” mueve el archivo de la zona staging a la zona directorio pero queda tracked por GIT.

Qué pasa que si ejecutas “git rm --cached file”?: Eliminas el archivo directamente de la
zona staging pero a demás su path y el archivo queda “Untracked” inrastreable, No lo
mueves a la zona directorio, lo eliminas por completo la memoria sin dejar rastros para
GIT, por lo tanto si deseas volver a la originalidad el archivo editado en la zona directorio
con el comando git restore file, “GIT no podrá restaurar los cambios”, hiciste un reset
memory del archivo en la ram o zona staging dejándolo fuera o chached de la memoria,
ahora espero que podramos entender que hace “git rm --cached file”.

git rm --force file: es mas potente todavía porque lo eliminas de la zona staging y de la zona
directorio, dicho en otras palabras los borras de GIT y del Disco Duro.

Hay que aclarar algo que puede confundir (Importante):

Cuando ejecutamos “git rm --cached file” y luego haces “git diff” observaras que “NO hay
diferencias” en el archivo que se encuentra en la zona directorio con respecto a la zona
repositorio (Ultimo commit), recuerda que este contiene la ultima versión del archivo en la
rama master.

Qué pasa? Git no lo detecta porque el archivo quedó eliminado y Untracked, pero en
realidad el archivo que está en el directorio está modificado y es diferente con respecto al
que se encuentra en la zona repositorio. si ejecutas el comando “git restore file”, GIT no
podrá Matchear el archivo con el que se encuentra en el directorio, los cambios que editaste
y salvaste no podrán deshacerse para volver al archivo original.

Qué podemos hacer para volver a rastrear el archivo y sea tracked por GIT: Luego de
ejecutar “git rm --cached file” podemos deshacer o restaurar los cambios con el comando
“git restore --staged file”, ahora hemos restablecido la comunicación y GIT puede
ayudarnos con el archivo porque esta tracked, pero NO esta en la zona staging, no te
confundas simplemente esta Tracked…ahora si podemos ejecutar el comando “git restore
file” y el archivo editado volverá a ser el original, todo quedará como lo encontraste!
Compruébalo con “git status”.

Finalmente quedan los comando que se ejecutan en la zona del repositorio o staging-
repositorio: git reset N#Commit --soft: borra todos los commit superiores y queda como el
commit master, el commit seleccionado en el comando, no hay vuelta atrás. a diferencia de
“git checkout #commit file”.

git reset N#Commit --hard: borra todos los commit superiores y queda como el commit
master, el commit seleccionado en el comando y además limpia la zona staging, no hay
vuelta atrás como dice la clase…borra todo todito! así que corran por sus vidas.

Git rm: Remover/Eliminar

 Git rm --cached: Elimina los archivos que están en staging (caché) pero los deja en
tu carpeta (disco duro).
 Git rm --force: Elimina el archivo de git y de tu carpeta (disco duro). _Los archivos
se pueden recuperar pero con comando avanzados.
Git reset: Ir a archivos pasados.

 Git resert --hard: Borra todo, del área de staging, commits e historial.
 Git reset --soft: Borra el historial y los registros pero mantiene los cambios
agregado a staging.
 Git reset HEAD: Imagina que hiciste ++git add++ a dos archivos, un HTML y otro
CSS. Sin embargo, te diste cuenta que no agregaste los estilos correctamente porque
los titulos son rojos. Haces git reset HEAD, tu archivo se quita de staging, vuelve a
tu carpeta, modificas el archivo css y vuelves a hacer ++git add++. Si hubieses
usado git rm tu archivo se hubiese eliminado.

Diferencias: git rm solo elimina archivos (ya sea de staging o del disco duro). git reset te
envía a versiones antiguas y elimina archivos, historial y registros.

Para iniciar nuestra práctica debemos ver el siguiente video, tener en cuenta que aun no
inciamos a ver GitHub.

https://www.youtube.com/watch?v=gjKKtQVVCZU

PRACTICA 1

Supongamos que tienes un repositorio de Git con un archivo llamado ejemplo.txt. Aquí
están los pasos de la práctica:

1. Crea un repositorio y realiza algunos commits:

bash
 git init # Inicializa un nuevo repositorio
echo "Versión 1" > ejemplo.txt
git add ejemplo.txt
git commit -m "Agregado ejemplo.txt con la versión 1"
echo "Versión 2" >> ejemplo.txt
git add ejemplo.txt
git commit -m "Actualizada a versión 2"

 Revisa el historial de commits:

bash
 git log

 Haz un cambio no deseado y reviértelo con revert:

bash
 echo "Cambio no deseado" >> ejemplo.txt
git add ejemplo.txt
git commit -m "Cambio no deseado"
git log # Verifica el hash del commit que quieres
revertir
git revert <hash_del_commit> # Revierte el cambio no deseado

 Usa reset para deshacer el último commit:

bash
 git log # Verifica el hash del último commit
git reset --hard HEAD~1 # Resetea al commit anterior, eliminando el
último

 Crea una rama, realiza cambios y luego vuelve a la rama principal con checkout:

bash
 git branch nueva-funcionalidad # Crea una nueva rama llamada
"nueva-funcionalidad"
git checkout nueva-funcionalidad # Cambia a la nueva rama
echo "Nueva funcionalidad" >> ejemplo.txt
git add ejemplo.txt
git commit -m "Agregada nueva funcionalidad"
git checkout master # Cambia de vuelta a la rama principal

 Combina los cambios de la nueva rama a la rama principal (merge):

bash
6. git merge nueva-funcionalidad # Fusiona los cambios de la rama
nueva-funcionalidad a la rama master

Recuerda, estas prácticas son mejor realizadas en un entorno de prueba para evitar cambios
no deseados en tu código. ¡Espero que esto te ayude a practicar tus habilidades de Git!

PRACTICA 2

Supongamos que tienes un repositorio de Git con una rama principal llamada main y una
rama de características llamada feature.

1. Crea un repositorio y realiza algunos commits:

bash
 git init # Inicializa un nuevo repositorio
echo "Versión 1" > ejemplo.txt
git add ejemplo.txt
git commit -m "Agregado ejemplo.txt con la versión 1"

 Crea una nueva rama de características y realiza algunos commits en ella:

bash
 git checkout -b feature # Crea y cambia a la nueva rama 'feature'
echo "Nueva funcionalidad" >> ejemplo.txt
git add ejemplo.txt
git commit -m "Agregada nueva funcionalidad"
 Regresa a la rama principal y realiza más commits:

bash
 git checkout main # Cambia a la rama 'main'
echo "Versión 2" >> ejemplo.txt
git add ejemplo.txt
git commit -m "Actualizada a versión 2 en la rama main"

 Rebasa la rama principal a la rama de características usando rebase interactivo:

bash
 git checkout feature # Cambia a la rama 'feature'
git rebase -i main # Inicia el rebase interactivo con la rama main

 Resuelve los conflictos, si los hay, durante el rebase interactivo: Durante el rebase
interactivo, es posible que aparezcan conflictos. Edita los archivos conflictivos, resuelve los
conflictos y luego continúa con el rebase:

bash
 git add . # Agrega los archivos resueltos
git rebase --continue # Continúa el rebase después de resolver los
conflictos

 Verifica el historial y realiza los cambios finales:

bash
6. git log # Verifica el historial para asegurarte de que
todo esté correcto

Recuerda, el rebase interactivo es una operación poderosa, pero debes usarla con
precaución, especialmente en colaboración con otros desarrolladores, ya que reescribe la
historia del repositorio. ¡Espero que esta práctica te ayude a mejorar tus habilidades en Git!