tag - ¿Por qué hay 2 formas de descomponer un archivo en git?

git remove tag (10)

A veces, git sugiere git rm --cached para eliminar 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 #

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 tienes un commit para cambiar tu puntero a
la única forma de ''sacar archivos del cubo al que se apunta'' es eliminar los archivos que le dijo a git para que observen 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 has comprometido, '' guardado ''

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 desestabilizar)

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

Este hilo es un poco antiguo, 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 ) muestra una advertencia sobre el archivo modificado y su código de salida es 1, que se considerará un error en un script.

Edición: git checkout HEAD to-be-modified to-be-removed también funciona para desempaquetar, pero elimina el cambio completamente del área de trabajo

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

git reset HEAD <file> elimina el archivo en la confirmación actual.
git rm --cached <file> también desestabilizará el archivo para futuras confirmaciones. No está en fase hasta que se agrega de nuevo con git add <file> .

Y hay una diferencia más importante:

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

Esta última diferencia es importante para los 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 de url, ip o puerto diferente), por lo que si está usando git rm --cached <file> cualquiera que extraiga su sucursal tendrá que volver a crear manualmente la configuración, o puede enviarlas las suyas y ellas pueden volver a editarlas a su configuración de IP (etc.), porque la eliminación solo afecta a las personas que retiran su sucursal del control remoto.

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

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 realiza un seguimiento de los cambios en el repositorio, sino que también realiza un seguimiento de las acciones del usuario (por ejemplo, extracción, verificación de diferentes ramas, etc.) y permite deshacer esas acciones. Entonces, en lugar de desempaquetar el archivo que se preparó erróneamente, puede volver al punto en el que no escaló los archivos.

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

Lo siento, no estoy respondiendo realmente a tu pregunta, pero solo señalo otra forma de desarreglar los archivos que uso con bastante frecuencia (por lo que a mí me gustan mucho las respuestas de Ryan Stewart y Waldyrious.);) Espero que te sirva de ayuda.

Muy simple:

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

Si el archivo no estaba en el control de revisión anteriormente (es decir, no está preparando un archivo que acaba de git add por primera vez), entonces los dos comandos tienen el mismo efecto, por lo que la apariencia de estos es "dos formas de haciendo algo".

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

_{** Por mucho tiempo tuve miedo de usar el comando git reset debido a su nombre, y aún hoy en día a menudo busco la sintaxis para asegurarme de no equivocarme.} _{( actualización : finalmente me tomé el tiempo de resumir el uso de git reset en 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).}

Si accidentalmente ha almacenado archivos que no desea confirmar y desea asegurarse de que conserva los cambios, también puede utilizar:

git stash git stash pop

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

Supongamos que ejecuta un directorio completo a través de git add <folder> , pero desea excluir un archivo de la lista por etapas (es decir, la lista que se genera al ejecutar el git status ) y mantener las modificaciones dentro del archivo excluido (estaba trabajando en algo). y no está listo para comprometerse, pero no quiere perder su trabajo ...). Usted podría simplemente utilizar:

git reset <file>

Cuando ejecute git status , verá que los archivos que reset están en unstaged y el resto de los archivos que added todavía están en la lista por staged .

git rm --cached <filePath> no elimina el escenario de un archivo, en realidad realiza la eliminación del (los) archivo (s) del repositorio (suponiendo que ya se había confirmado antes) pero deja el archivo en su árbol de trabajo (dejándolo sin un seguimiento) expediente).

git reset -- <filePath> anulará los cambios preconfigurados para los archivos dados.

Dicho esto, si usó git rm --cached en un archivo nuevo que está almacenado, básicamente parecería que no lo estaba, ya que nunca antes se había cometido.

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

git reset HEAD file (que de forma predeterminada utiliza el indicador --mixed ) 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), efectivamente Unstaging las modificaciones a ella.

En el caso de un archivo no versionado, se desorganizará todo el archivo ya que el archivo no estaba en la CABEZA. En este aspecto, git reset HEAD file y git rm --cached son iguales, pero no son iguales (como se explica en el caso de 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 manera de hacer algo en git. Esa es la belleza de esto :)