A veces, git sugiere git rm --cachedeliminar el escenario de un archivo, a veces git reset HEAD file. ¿Cuándo debo usar cuál?

EDITAR:

D:\code\gt2>git init
Initialized empty Git repository in D:/code/gt2/.git/
D:\code\gt2>touch a

D:\code\gt2>git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       a
nothing added to commit but untracked files present (use "git add" to track)

D:\code\gt2>git add a

D:\code\gt2>git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   a
#
D:\code\gt2>git commit -m a
[master (root-commit) c271e05] a
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 a

D:\code\gt2>touch b

D:\code\gt2>git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       b
nothing added to commit but untracked files present (use "git add" to track)

D:\code\gt2>git add b

D:\code\gt2>git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   b
#

git rm --cached <filePath> no desestabiliza un archivo, en realidad realiza la eliminación de los archivos del repositorio (suponiendo que ya se haya confirmado antes) pero deja el archivo en su árbol de trabajo (dejándolo con un archivo sin seguimiento).

git reset -- <filePath>se unstage cualquier organizaron cambios para el archivo (s) dado.

Dicho esto, si usaste git rm --cachedun nuevo archivo que está en escena, básicamente parecería que lo has desarmado ya que nunca antes se había confirmado.

Actualice git 2.24
En esta nueva versión de git puede usar en git restore --stagedlugar de git reset. Ver git docs .

git rm --cachedse usa para eliminar un archivo del índice. En el caso de que el archivo ya esté en el repositorio, git rm --cachedeliminará el archivo del índice, dejándolo en el directorio de trabajo y una confirmación ahora también lo eliminará del repositorio. Básicamente, después de la confirmación, habría desversionado el archivo y mantenido una copia local.

git reset HEAD file(que de forma predeterminada está usando el --mixedindicador) es diferente en el caso de que el archivo ya esté en el repositorio, reemplaza la versión de índice del archivo con la del repositorio (HEAD), eliminando efectivamente las modificaciones .

En el caso de un archivo no versionado, va a quitar el escenario del archivo completo ya que el archivo no estaba allí en el HEAD. En este aspecto git reset HEAD filey git rm --cachedson iguales, pero no son iguales (como se explica en el caso de los archivos que ya están en el repositorio)

A la pregunta de Why are there 2 ways to unstage a file in git?: nunca hay realmente una sola forma de hacer algo en git. esa es la belleza de eso :)

Muy simple:

• git rm --cached <file> hace que git deje de rastrear el archivo por completo (dejándolo en el sistema de archivos, a diferencia de simple git rm*)
• git reset HEAD <file> elimina las modificaciones realizadas en el archivo desde la última confirmación (pero no las revierte en el sistema de archivos, al contrario de lo que el nombre del comando podría sugerir **). El archivo permanece bajo control de revisión.

Si el archivo no estaba en control de revisión antes (es decir, está desestabilizando un archivo que acababa de editar git addpor primera vez), entonces los dos comandos tienen el mismo efecto, de ahí la apariencia de que son "dos formas de hacer algo ".

_{* Tenga en cuenta la advertencia que @DrewT menciona en su respuesta, con respecto git rm --cacheda un archivo que se había enviado previamente al repositorio. En el contexto de esta pregunta, de un archivo que se acaba de agregar y aún no se ha confirmado, no hay nada de qué preocuparse.}

_{** Tenía miedo por un tiempo vergonzosamente largo de usar el comando git reset debido a su nombre, y aún hoy a menudo busco la sintaxis para asegurarme de no equivocarme. ( actualización : finalmente me tomé el tiempo para resumir el uso de git reseten una página tldr , así que ahora tengo un mejor modelo mental de cómo funciona, y una referencia rápida para cuando olvide algunos detalles).}

Este hilo es un poco viejo, pero todavía quiero agregar una pequeña demostración ya que todavía no es un problema intuitivo:

me$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   to-be-added
#   modified:   to-be-modified
#   deleted:    to-be-removed
#

me$ git reset -q HEAD to-be-added

    # ok

me$ git reset -q HEAD to-be-modified

    # ok

me$ git reset -q HEAD to-be-removed

    # ok

# or alternatively:

me$ git reset -q HEAD to-be-added to-be-removed to-be-modified

    # ok

me$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   to-be-modified
#   deleted:    to-be-removed
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   to-be-added
no changes added to commit (use "git add" and/or "git commit -a")

git reset HEAD(sin -q) da una advertencia sobre el archivo modificado y su código de salida es 1, que se considerará como un error en un script.

Editar: git checkout HEAD to-be-modified to-be-removedtambién funciona para desestabilizar, pero elimina el cambio por completo del espacio de trabajo

Actualización git 2.23.0: de vez en cuando, los comandos cambian. Ahora git statusdice:

  (use "git restore --staged <file>..." to unstage)

... que funciona para los tres tipos de cambio

si accidentalmente organizó archivos que no le gustaría confirmar y desea asegurarse de mantener los cambios, también puede usar:

git stash
git stash pop

Esto realiza un restablecimiento a HEAD y vuelve a aplicar sus cambios, lo que le permite volver a organizar los archivos individuales para la confirmación. Esto también es útil si ha olvidado crear una rama de características para solicitudes de extracción ( git stash ; git checkout -b <feature> ; git stash pop).

Estos 2 comandos tienen varias diferencias sutiles si el archivo en cuestión ya está en el repositorio y bajo control de versión (previamente comprometido, etc.):

• git reset HEAD <file> desestabiliza el archivo en la confirmación actual.
• git rm --cached <file>también quitará el escenario del archivo para futuras confirmaciones. No está en escena hasta que se agrega nuevamente git add <file>.

Y hay una diferencia más importante:

• Después de ejecutar git rm --cached <file>y empujar su rama al control remoto, cualquier persona que extraiga su rama del control remoto eliminará REALMENTE el archivo de su carpeta, aunque en su conjunto de trabajo local el archivo simplemente no se rastrea (es decir, no se elimina físicamente de la carpeta).

Esta última diferencia es importante para proyectos que incluyen un archivo de configuración en el que cada desarrollador del equipo tiene una configuración diferente (es decir, una configuración base de URL, IP o puerto diferente), por lo que si está utilizando a git rm --cached <file>alguien que extraiga su rama, tendrá que volver a cree la configuración, o puede enviarles la suya y pueden volver a editarla a su configuración de IP (etc.), porque la eliminación solo afecta a las personas que extraen su rama del control remoto.

Supongamos que utiliza stageun directorio completo git add <folder>, pero desea excluir un archivo de la lista por etapas (es decir, la lista que se genera cuando se ejecuta git status) y mantener las modificaciones dentro del archivo excluido (estaba trabajando en algo y no está listo para la confirmación, pero no quieres perder tu trabajo ...). Simplemente podrías usar:

git reset <file>

Cuando corras git status, verás que cualesquiera que sean los archivos que reseteres unstagedy el resto de los archivos queadded se encuentran todavía en la stagedlista.

1)

D:\code\gt2>git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   a

(use "git rm --cached ..." para quitar el escenario)

• git es un sistema de punteros

• aún no tiene una confirmación para cambiar su puntero a

• la única forma de 'sacar archivos del cubo al que se apunta' es eliminar los archivos que le dijiste a git que esté atento a los cambios

2)

D:\code\gt2>git commit -m a
[master (root-commit) c271e05] a
0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 a

git commit -ma

• te comprometiste, ' salvaste '

3)

D:\code\gt2>git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   b
#

(use "git reset HEAD ..." para quitar el escenario)

• Hiciste una confirmación en tu código en este momento
• ahora puede restablecer su puntero a su confirmación ' volver al último guardado '

Me sorprende que nadie haya mencionado el git reflog ( http://git-scm.com/docs/git-reflog ):

# git reflog
<find the place before your staged anything>
# git reset HEAD@{1}

El reflog es un historial de git que no solo rastrea los cambios en el repositorio, sino que también rastrea las acciones del usuario (por ejemplo, pull, checkout a una rama diferente, etc.) y permite deshacer esas acciones. Entonces, en lugar de quitar el escenario del archivo que se preparó por error, donde puede volver al punto en el que no organizó los archivos.

Esto es similar git reset HEAD <file>pero en ciertos casos puede ser más granular.

Lo siento, no estoy respondiendo realmente a tu pregunta, pero solo estoy señalando otra forma de eliminar el contenido de los archivos que uso con bastante frecuencia (por mi parte, me gustan las respuestas de Ryan Stewart y waldyrious). Espero que sea útil.

Solo usa:

git reset HEAD <filename>

Esto desestabiliza el archivo y mantiene los cambios que le hizo, por lo que puede, a su vez, cambiar las ramas si lo desea y git addesos archivos a otra rama. Todos los cambios se mantienen.

Me parece que git rm --cached <file>elimina el archivo del índice sin eliminarlo del directorio donde un plano git rm <file>haría ambas cosas, al igual que un sistema operativo rm <file>eliminaría el archivo del directorio sin eliminar su versión.

Solo para las versiones 2.23 y superiores,

En lugar de estas sugerencias, puede usarlas git restore --staged <file>para unstagelos archivos.