¿“Git rm - x en caché” frente a “git reset head - x”?

GitRef.org - Básico :

git rmeliminará las entradas del área de preparación. Esto es un poco diferente de lo git reset HEADque "desestabiliza" archivos. Al decir "unstage" quiero decir que revierte el área de preparación a lo que estaba allí antes de comenzar a modificar las cosas. git rmpor otro lado, simplemente saca el archivo del escenario por completo, de modo que no se incluye en la siguiente instantánea de confirmación, por lo que se elimina de manera efectiva.

Por defecto, a git rm fileeliminará el archivo del área de preparación por completo y también de su disco> (el directorio de trabajo). Para dejar el archivo en el directorio de trabajo, puede usar git rm --cached.

Pero, ¿cuál es exactamente la diferencia entre git rm --cached asdy git reset head -- asd?

Hay tres lugares donde puede estar un archivo, por ejemplo, el árbol, el índice y la copia de trabajo. Cuando solo agrega un archivo a una carpeta, lo agrega a la copia de trabajo.

Cuando haces algo como git add filelo agregas al índice. Y cuando lo comprometes, también lo agregas al árbol.

Probablemente te ayudará a conocer las tres banderas más comunes en git reset:

git reset [- <mode>] [ <commit>]

Este formulario restablece el encabezado de la rama actual <commit>y posiblemente actualiza el índice (restableciéndolo al árbol de <commit>) y el árbol de trabajo según <mode>, que debe ser uno de los siguientes:
--soft

No toca el archivo de índice ni el árbol de trabajo en absoluto (pero reinicia la cabeza <commit>, al igual que todos los modos). Esto deja todos los archivos modificados "Cambios a confirmar", como lo indicaría el estado de git.

--mezclado

Restablece el índice pero no el árbol de trabajo (es decir, los archivos modificados se conservan pero no se marcan para confirmar) e informa lo que no se ha actualizado. Esta es la acción por defecto.

--difícil

Restablece el índice y el árbol de trabajo. Cualquier cambio en los archivos rastreados en el árbol de trabajo desde entonces <commit>se descarta.

Ahora, cuando hace algo como git reset HEAD: lo que realmente está haciendo es git reset HEAD --mixedy "restablecerá" el índice al estado que tenía antes de comenzar a agregar archivos / agregar modificaciones al índice (vía git add) En este caso, la copia de trabajo y el El índice (o la puesta en escena) estaban sincronizados, pero hizo que HEAD y el índice estuvieran sincronizados después del restablecimiento.

git rmpor otro lado, elimina un archivo del directorio de trabajo y del índice, y cuando confirma, el archivo también se elimina del árbol. git rm --cachedsin embargo, elimina el archivo solo del índice y lo mantiene en su copia de trabajo. Esto es exactamente lo contrario de git add file En este caso, hizo que el índice fuera diferente del HEAD y del trabajo, ya que HEAD tiene la versión previamente comprometida del archivo, la copia de trabajo tuvo la última modificación, si la hubo, o el contenido del HEAD de el archivo y eliminó el archivo del índice. Una confirmación ahora sincronizará el índice y el árbol y se eliminará el archivo.

Quizás un ejemplo ayude:

git rm --cached asd
git commit -m "the file asd is gone from the repository"

versus

git reset HEAD -- asd
git commit -m "the file asd remains in the repository"

Tenga en cuenta que si no ha cambiado nada más , la segunda confirmación en realidad no hará nada.

git rm --cached filese quite el archivo desde el escenario. Es decir, cuando confirme el archivo será eliminado. git reset HEAD -- filesimplemente restablecerá el archivo en el área de preparación al estado donde estaba en la confirmación HEAD, es decir, deshacerá cualquier cambio que haya realizado desde la última confirmación. Si ese cambio sucede al agregar nuevamente el archivo, entonces serán equivalentes.