35 Pregunta: ¿Cómo deshago 'git add' antes de confirmar?

pregunta creada en Mon, Jun 10, 2019 12:00 AM

Por error, agregué archivos a git usando el comando:

 
git add myfile.txt

Todavía no he ejecutado git commit. ¿Hay alguna forma de deshacer esto, por lo que estos archivos no se incluirán en la confirmación?

    
8195
  1. Comenzando con Git v1.8.4, todas las respuestas a continuación que usan HEAD o head ahora pueden usar @ en lugar de HEAD. Consulte esta respuesta (última sección) para saber por qué puede haz eso.
    2013-07-26 02: 04: 14Z
  2. Hice un pequeño resumen que muestra todas las formas de descomponer un archivo: stackoverflow.com/questions/6919121/…
    2014-04-26 12: 09: 03Z
  3. ¿Por qué no git checkout?
    2016-09-05 14: 57: 00Z
  4. @ ErikReppen git checkout no elimina los cambios por etapas del índice de confirmación. Solo revierte los cambios no escalonados a la última revisión confirmada, que por cierto tampoco es lo que quiero, quiero esos cambios, solo los quiero en una confirmación posterior.
    2016-09-06 21: 08: 58Z
  5. Si usa Eclipse, es tan simple como desmarcar los archivos en el cuadro de diálogo de confirmación
    2016-11-17 12: 49: 17Z
30 Respuestas                              30                         

Puede deshacer git add antes de confirmar con

 
git reset <file>

que lo eliminará del índice actual (la lista "a punto de comprometerse") sin cambiar nada más.

Puedes usar

 
git reset

sin ningún nombre de archivo para eliminar todos los cambios debidos. Esto puede ser útil cuando hay demasiados archivos para ser listados uno por uno en un tiempo razonable.

En las versiones anteriores de Git, los comandos anteriores son equivalentes a git reset HEAD <file> y git reset HEAD respectivamente, y fallarán si HEAD no está definido (porque aún no has confirmado nada en tu repositorio) o ambiguo (porque creaste una rama llamada HEAD, que es una cosa estúpida que no debes hacer). Este se cambió en Git 1.8. 2 , sin embargo, así que en las versiones modernas de Git puedes usar los comandos anteriores incluso antes de hacer tu primer confirmación:

  

"git reset" (sin opciones o parámetros) usado para errores cuando      No tienes ningún compromiso en tu historia, pero ahora te da      un índice vacío (para coincidir con un compromiso inexistente en el que ni siquiera está).

    
9303
2015-10-29 23: 04: 30Z
  1. Por supuesto, esto no es un verdadero deshacer, porque si el git add incorrecto sobrescribió una versión no comprometida anterior, no podemos recuperarla. Intenté aclarar esto en mi respuesta a continuación.
    2013-05-06 19: 10: 43Z
  2. git reset HEAD *.ext donde ext son los archivos de la extensión dada que desea agregar. Para mí fue *.bmp y amp; *.zip
    2013-11-26 14: 25: 19Z
  3. @ Jonny, el índice (también conocido como área de almacenamiento) contiene todos los archivos, no solo los archivos modificados. Se "inicia la vida" (cuando verifica un commit o clona un repositorio) como una copia de todos los archivos en el commit apuntado por HEAD. Así que si eliminas un archivo del índice (git rm --cached) significa que se está preparando para confirmar que elimina ese archivo. Por otra parte, git reset HEAD <filename> copiará el archivo de HEAD al índice, de modo que la próxima confirmación no mostrará ningún cambio realizado en ese archivo.
    2016-03-16 12: 27: 34Z
  4. Acabo de descubrir que hay un git reset -p como el git add -p. ¡Esto es increíble!
    2016-07-17 23: 23: 05Z
  5. En realidad, puede recuperar los cambios sobrescritos previamente almacenados pero no comprometidos pero no de una manera amigable para el usuario y no 100% seguro (al menos ninguno que haya encontrado ): vaya a .git /objects, busque los archivos creados en el momento de git add que desea recuperar (61/3AF3... - > id de objeto 613AF3...), luego git cat-file -p <object-id> (podría valer la pena recuperar varias horas de trabajo, pero también una lección para cometer) más a menudo ...)
    2017-07-31 14: 03: 25Z

Quieres:

 
git rm --cached <added_file_to_undo>

Razonamiento:

Cuando era nuevo en esto, lo intenté por primera vez

 
git reset .

(para deshacer mi adición inicial completa), solo para recibir este (no tan) útil mensaje:

 
fatal: Failed to resolve 'HEAD' as a valid ref.

Resulta que esto se debe a que el HEAD ref (branch?) no existe hasta después de la primera confirmación. Es decir, se encontrará con el mismo problema de principiante que yo si su flujo de trabajo, como el mío, fuera algo como:

  1. cd a mi gran directorio de nuevos proyectos para probar Git, el nuevo hotness
  2. git init
  3. git add .
  4. git status

    ... un montón de pergaminos por ...

    = > Maldita sea, no quería agregar todo eso.

  5. google "deshacer git agregar"

    = > encontrar desbordamiento de pila - yay

  6. git reset .

    = > fatal: no se pudo resolver 'HEAD' como una referencia válida.

Además, resulta que hay un error registrado en contra la inutilidad de esto en la lista de correo.

Y que la solución correcta estaba allí mismo en la salida de estado de Git (que, sí, pasé por alto como 'basura]

 
...
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
...

Y, de hecho, la solución es utilizar git rm --cached FILE.

Tenga en cuenta las advertencias en otros lugares aquí: git rm elimina su copia de trabajo local del archivo, pero no si usa --cached . Aquí está el resultado de git help rm:

  

--cached       Utilice esta opción para quitar el escenario y eliminar las rutas solo del índice.       Los archivos del árbol de trabajo, ya sean modificados o no, se dejarán.

procedo a utilizar

 
git rm --cached .

para eliminar todo y empezar de nuevo. Sin embargo, no funcionó, ya que si bien add . es recursivo, resulta que rm necesita -r para ser recursivo. Suspiro.

 
git rm -r --cached .

Bien, ahora he vuelto a donde empecé. La próxima vez voy a usar -n para hacer un recorrido en seco y ver qué se agregará:

 
git add -n .

Guardé todo en un lugar seguro antes de confiar en el git help rm acerca de que el --cached no destruyó nada (y si lo escribo mal).

    
2062
2018-09-13 00: 05: 11Z
  1. Hah. Seguí este mismo proceso. Excepto que me rendí y dije rm -rf .git, git init porque no confiaba en git rm --cached para mantener mi copia de trabajo. Dice un poco de cómo git todavía es demasiado complejo en algunos lugares. git unstage debería ser un comando estándar, no me importa si puedo agregarlo como un alias.
    2011-03-29 03: 45: 18Z
  2. Para mí, git dice git reset HEAD <File>...
    2012-09-12 06: 50: 13Z
  3. git rm --cached < file > En realidad, es la respuesta correcta, si es la importación inicial de < file > en el repositorio. Si está intentando desestabilizar un cambio en el archivo, git reset es la respuesta correcta. Las personas que dicen que esta respuesta es incorrecta están pensando en una pregunta diferente.
    2013-02-28 22: 14: 57Z
  4. Esto realmente funcionará, pero solo en la first commit, donde el archivo no existía antes, o donde el comando git add agregó nuevos archivos, pero no cambia a los archivos existentes.
    2013-04-10 02: 33: 36Z
  5. solo muestra lo poco intuitivo y complicado que es git. En lugar de tener comandos paralelos de "deshacer", debe descubrir cómo deshacerlos. Como intentar liberar tu pierna con arena rápida, y luego atascarte el brazo, luego atascar el otro brazo ... cada comando se debe hacer a través de la GUI, con elementos de menús desplegables para las opciones ... Piensa en toda la interfaz de usuario, hemos tenido ganancias de productividad, pero tenemos este lío de una interfaz de línea de comandos retro. No es como los programas GUI de git hacen que esto sea más intuitivo.
    2014-05-24 10: 54: 36Z

Si escribe:

 
git status

git le dirá lo que está en escena, etc., incluidas las instrucciones sobre cómo cancelar el escenario:

 
use "git reset HEAD <file>..." to unstage

Encuentro que git hace un buen trabajo al obligarme a hacer lo correcto en situaciones como esta.

Nota: las versiones recientes de git (1.8.4.x) han cambiado este mensaje:

 
(use "git rm --cached <file>..." to unstage)
    
507
2013-11-09 03: 48: 01Z
  1. El mensaje será diferente dependiendo de si el archivo add ed ya estaba siendo rastreado (el add solo guardó una nueva versión en el caché; aquí aparecerá su mensaje) . En otros lugares, si el archivo no se almacenó previamente, se mostrará use "git rm --cached <file>..." to unstage
    2013-05-06 18: 25: 26Z
  2. ¡Genial! El git reset HEAD <file> uno es el único que funcionará en caso de que desee cancelar la etapa de eliminación de un archivo
    2018-02-24 00: 25: 25Z
  3. Mi versión 2.14.3 de git dice git reset HEAD para dejar el escenario.
    2018-04-23 19: 16: 53Z

Para aclarar: git add mueve los cambios del directorio de trabajo actual al área de preparación (índice).

Este proceso se llama puesta en escena . Así que el comando más natural para etapa los cambios (archivos modificados) es el obvio:

 
git stage

git add es simplemente un alias para git stage

Lástima que no hay git unstage ni git unadd comandos. El relevante es más difícil de adivinar o recordar, pero es bastante obvio:

 
git reset HEAD --

Podemos crear fácilmente un alias para esto:

 
git config --global alias.unadd 'reset HEAD --'
git config --global alias.unstage 'reset HEAD --'

Y finalmente, tenemos nuevos comandos:

 
git add file1
git stage file2
git unadd file2
git unstage file1

Personalmente uso alias aún más cortos:

 
git a #for staging
git u #for unstaging
    
240
2013-04-29 13: 05: 17Z
  1. "mueve"? Esto indicaría que se ha ido desde el directorio de trabajo. Ese no es el caso.
    2017-06-08 09: 18: 33Z
  2. ¿Por qué es obvio?
    2017-06-23 18: 25: 52Z
  3. En realidad, git stage es el alias de git add, que es el comando histórico, tanto en Git como en otro SCM. Se ha añadido en diciembre de 2008 con commit 11920d28da en el "repositorio de git de Git", si puedo decir.
    2018-09-12 18: 13: 20Z

Una adición a la respuesta aceptada, si su archivo agregado por error fue enorme, probablemente notará que, incluso después de eliminarlo del índice con 'git reset', todavía parece ocupar espacio en el directorio .git. Esto no es nada de qué preocuparse, el archivo es inde.Aún en el repositorio, pero solo como un "objeto suelto", no se copiará a otros repositorios (a través de clonación, inserción), y el espacio se recuperará eventualmente, aunque quizás no muy pronto. Si estás ansioso, puedes correr:

 
git gc --prune=now

Actualizar (lo que sigue es mi intento de aclarar algunas confusiones que pueden surgir de las respuestas más votadas):

Entonces, ¿cuál es el verdadero deshacer de git add?

git reset HEAD <file>?

o

git rm --cached <file>?

Estrictamente hablando, y si no me equivoco: ninguno .

git add no se puede deshacer , de manera segura, en general.

Recordemos primero lo que hace realmente el git add <file>:

  1. Si <file> no fue rastreado previamente , git add lo agrega a la caché , con su contenido actual.

  2. Si <file> ya era ya rastreado , git add guarda el contenido actual (instantánea, versión) en el caché. En GIT, esta acción aún se llama agregar , (no es mera actualizar ), porque dos versiones diferentes (instantáneas) de un archivo se consideran como dos elementos diferentes: por lo tanto, de hecho, estamos agregando un nuevo elemento a la memoria caché, que luego se enviará posteriormente.

A la luz de esto, la pregunta es ligeramente ambigua:

  

Agregué erróneamente archivos con el comando ...

El escenario del OP parece ser el primero (archivo sin seguimiento), queremos que el "deshacer" elimine el archivo (no solo el contenido actual) de los elementos rastreados. Si este es el caso, entonces está bien ejecutar git rm --cached <file>.

Y también podríamos correr git reset HEAD <file>. En general, esto es preferible porque funciona en ambos escenarios: también se deshace cuando agregamos erróneamente una versión de un elemento ya rastreado.

Pero hay dos advertencias.

Primero: hay (como se señaló en la respuesta) solo un escenario en el que git reset HEAD no funciona, pero git rm --cached sí: un nuevo repositorio (sin confirmaciones). Pero, en realidad, este es un caso prácticamente irrelevante.

Segundo: tenga en cuenta que el git reset HEAD no puede recuperar mágicamente el contenido del archivo previamente almacenado en caché, simplemente lo vuelve a sincronizar desde HEAD. Si nuestro git add equivocado sobreescribió una versión anterior no comprometida, no podemos recuperarla. Es por eso que, estrictamente hablando, no podemos deshacer [*].

Ejemplo:

 
$ git init
$ echo "version 1" > file.txt
$ git add file.txt   # first add  of file.txt
$ git commit -m 'first commit'
$ echo "version 2" > file.txt
$ git add  file.txt   # stage (don't commit) "version 2" of file.txt
$ git diff --cached file.txt
-version 1
+version 2
$ echo "version 3" > file.txt   
$ git diff  file.txt
-version 2
+version 3
$ git add  file.txt    # oops we didn't mean this
$ git reset HEAD file.txt  # undo ?
$ git diff --cached file.txt  # no dif, of course. stage == HEAD
$ git diff file.txt   # we have lost irrevocably "version 2"
-version 1
+version 3

Por supuesto, esto no es muy crítico si seguimos el flujo de trabajo perezoso habitual de hacer 'git add' solo para agregar nuevos archivos (caso 1), y actualizamos los nuevos contenidos a través del comando commit, git commit -a.


* (Edición: lo anterior es prácticamente correcto, pero aún puede haber algunas formas leves /complicadas para recuperar los cambios que se realizaron, pero no se confirmaron y se sobrescribieron, consulte los comentarios de Johannes Matokic y iolsmit)

    
161
2018-10-15 17: 23: 57Z
  1. Hablando estrictamente, hay una manera de recuperar un archivo ya almacenado que fue reemplazado por git add. Como mencionó, git add crea un objeto git para ese archivo que se convertirá en un objeto suelto, no solo cuando se elimina el archivo por completo, sino también cuando se sobrescribe con contenido nuevo. Pero no hay comando para recuperarlo automáticamente. En su lugar, el archivo debe identificarse y extraerse manualmente o con herramientas escritas solo para este caso (libgit2 lo permitirá). Pero esto solo se pagará si el archivo es muy importante y grande y no se puede reconstruir editando la versión anterior.
    2017-12-06 13: 07: 37Z
  2. Para corregirme: una vez que se encuentre el archivo de objetos sueltos (use metadatos como la fecha /hora de creación), git cat-file podría usarse para recuperar su contenido.
    2017-12-06 13: 22: 17Z
  3. Otra forma de recuperar cambios que se realizaron por etapas pero no se confirmaron y luego se sobrescribieron por ejemplo. otro git add es a través de git fsck --unreachable que listará todos los objetos inaccesibles, que luego puede inspeccionar con git show SHA-1_ID o git fsck --lost-found que escribirán objetos colgantes en .git/lost-found/commit/ o .git/lost-found/other/, dependiendo del tipo. Véase también git fsck --help
    2018-04-27 15: 29: 46Z
 
git rm --cached . -r

"anulará" todo lo que hayas agregadom su directorio actual recursivamente

    
92
2013-05-28 15: 18: 28Z
  1. No estaba buscando deshacer todo, solo UN archivo específico.
    2009-12-09 22: 35: 27Z
  2. También es útil si no tiene ninguna confirmación previa. En ausencia de una confirmación previa, git reset HEAD <file> diría fatal: Failed to resolve 'HEAD' as a valid ref.
    2013-06-02 03: 46: 13Z
  3. No, este agrega una eliminación de todo lo que se encuentra en su directorio actual. Muy diferente a los cambios que no son por etapas.
    2015-10-30 01: 33: 56Z

Ejecutar

 
git gui

y elimine todos los archivos manualmente o seleccionándolos todos y haciendo clic en el botón unstage from commit

    
85
2013-03-09 11: 21: 19Z
  1. Sí, lo entiendo. Solo quería sugerirte de forma implícita que indicas que en tu respuesta, como "Puedes usar git-gui ...." :)
    2014-08-01 16: 11: 05Z
  2. Dice, "git-gui: comando no encontrado". No estoy seguro de si esto funciona.
    2017-09-13 04: 19: 18Z
  3. Wow, esto es mucho más simple haciendo líneas de comando que no entendiste. Esto es definitivamente recomendado para un principiante como yo. ¡Gracias por escribir esto!
    2019-04-11 04: 27: 43Z

Deshacer un archivo que ya se agregó es bastante fácil de usar git , para restablecer myfile.txt que ya se agregó, use:

 
git reset HEAD myfile.txt

Explain:

Una vez que haya preparado los archivos no deseados, para deshacerlos, puede hacer git reset, Head es el encabezado de su archivo en local y el último parámetro es el nombre de su archivo.

Creo los pasos en la imagen a continuación con más detalles para usted, incluidos todos los pasos que pueden ocurrir en estos casos:

 git reset HEAD file>> </a> </p>
    </div>
<div class = 85

2019-03-21 09: 34: 42Z
  1. INCREÍBLE !!!!!!!!!!!!!!!!!!!!!
    2019-03-26 12: 56: 08Z

Git tiene comandos para cada acción imaginable, pero necesita un amplio conocimiento para hacer las cosas bien y, por eso, es contraintuitivo en el mejor de los casos ...

Lo que hiciste antes:

  • Cambió un archivo y usó git add . o git add <file>.

Lo que quieres:

  • Elimine el archivo del índice, pero manténgalo actualizado y deje los cambios sin confirmar en la copia de trabajo:

     
    git reset head <file>
    
  • Restablezca el archivo al último estado desde HEAD, deshaga los cambios y elimínelos del índice:

     
    # Think `svn revert <file>` IIRC.
    git reset HEAD <file>
    git checkout <file>
    
    # If you have a `<branch>` named like `<file>`, use:
    git checkout -- <file>
    

    Esto es necesario ya que git reset --hard HEAD no funcionará con archivos individuales.

  • Elimine <file> del índice y las versiones, manteniendo el archivo sin versión con cambios en la copia de trabajo:

     
    git rm --cached <file>
    
  • Elimine <file> de la copia de trabajo y las versiones completamente:

     
    git rm <file>
    
80
2015-10-30 01: 37: 07Z
  1. No puedo entender la diferencia de 'git reset head < file >' y 'git rm --cached < file &gt ;. ¿Podrías explicarlo?
    2013-08-14 00: 39: 07Z
  2. Los archivos @ jeswang son 'conocidos' por git (los cambios en ellos se están rastreando), o no están 'versionados'. reset head deshace sus cambios actuales, pero el archivo todavía está siendo supervisado por git. rm --cached elimina el archivo del control de versiones, por lo que git ya no lo comprueba en busca de cambios (y también elimina los cambios actuales eventualmente indexados, indicados a git por el anterior add), pero el archivo modificado se guardará en su copia de trabajo. carpeta de archivos en el disco duro.
    2013-08-15 15: 09: 40Z
  3. La diferencia es que git reset HEAD <file> es temporal: el comando se aplicará solo a la siguiente confirmación, pero git rm --cached <file> se eliminará hasta que se agregue nuevamente con git add <file>. Además, git rm --cached <file> significa que si empuja esa rama hacia el control remoto, cualquier persona que tire de la rama obtendrá el archivo de su carpeta de forma REAL.
    2014-08-10 19: 54: 43Z

La pregunta no está planteada claramente. La razón es que git add tiene dos significados:

  1. agregar un nuevo archivo al área de preparación, luego deshacer con git rm --cached file.
  2. agregar un archivo modificado al área de preparación, luego deshacer con git reset HEAD file.

en caso de duda, utilice

 
git reset HEAD file

Porque hace lo esperado en ambos casos.

Advertencia: si haces git rm --cached file en un archivo que fue modificado (un archivo que existía antes en el repositorio), ¡el archivo se eliminará en git commit! Seguirá existiendo en su sistema de archivos, pero si alguien más extrae su confirmación, el archivo se eliminará de su árbol de trabajo.

git status le dirá si el archivo era un nuevo archivo o modificado :

 
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   my_new_file.txt
    modified:   my_modified_file.txt
    
73
2015-10-30 23: 47: 29Z
  1. + 1. Un número extraordinario de respuestas y comentarios altamente actualizados en esta página son simplemente erróneos sobre el comportamiento del git rm --cached somefile. Espero que esta respuesta llegue a una posición prominente donde pueda proteger a los novatos de ser engañados por todas las afirmaciones falsas.
    2015-10-30 23: 44: 32Z
  2. una de las mejores respuestas aquí, lamentablemente es bastante bajo en la lista
    2019-06-10 01: 10: 36Z

Si está en su compromiso inicial y no puede usar git reset, simplemente declare "Git quiebra" y elimine la carpeta .git y comience de nuevo

    
62
2019-02-17 12: 01: 36Z
  1. Un consejo es copiar su archivo .git /config si ha agregado un origen remoto, antes de eliminar la carpeta.
    2010-03-08 23: 15: 52Z
  2. @ El comentario de ChrisJohnsen es acertado. A veces, desea confirmar todos los archivos excepto uno: git add -A && git rm --cached EXCLUDEFILE && git commit -m 'awesome commit' (esto también funciona cuando no hay confirmaciones anteriores, re Failed to resolve 'HEAD' problema)
    2013-03-29 04: 20: 41Z

Según muchas de las otras respuestas, puede utilizar git reset

BUT:

Encontré este pequeño gran post que agrega el Gicomando t (así como un alias) para git unadd: vea git unadd para más detalles o ...

Simplemente,

 
git config --global alias.unadd "reset HEAD"

Ahora puedes

 
git unadd foo.txt bar.txt
    
55
2016-07-13 16: 51: 08Z

git remove o git rm se pueden usar para esto, con la bandera --cached. Prueba:

 
git help rm
    
45
2013-03-09 11: 14: 55Z
  1. ¿Esto no eliminará el archivo por completo?
    2015-08-26 05: 29: 10Z
  2. git rm --cached ... eliminará los archivos de un repositorio de git. Seguirán existiendo en su computadora, pero esto es MUY diferente de los cambios en un archivo. Para cualquiera que se encuentre con esto, no es una respuesta válida a la pregunta.
    2018-12-17 20: 02: 59Z

Utilice git add -i para eliminar los archivos recién agregados de su próxima confirmación. Ejemplo:

Agregando el archivo que no querías:

 
$ git add foo
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   foo
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
# [...]#

Entrar en el complemento interactivo para deshacer el agregado (los comandos que se escriben en git aquí son "r" (revertir), "1" (la primera entrada en la lista revertir muestra), 'regresar' para salir del modo revertir, y "q" (salir):

 
$ git add -i
           staged     unstaged path
  1:        +1/-0      nothing foo

*** Commands ***
  1: [s]tatus     2: [u]pdate     3: [r]evert     4: [a]dd untracked
  5: [p]atch      6: [d]iff       7: [q]uit       8: [h]elp
What now> r
           staged     unstaged path
  1:        +1/-0      nothing [f]oo
Revert>> 1
           staged     unstaged path
* 1:        +1/-0      nothing [f]oo
Revert>> 
note: foo is untracked now.
reverted one path

*** Commands ***
  1: [s]tatus     2: [u]pdate     3: [r]evert     4: [a]dd untracked
  5: [p]atch      6: [d]iff       7: [q]uit       8: [h]elp
What now> q
Bye.
$

Eso es todo! Aquí está su prueba, que muestra que "foo" está nuevamente en la lista sin seguimiento:

 
$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
# [...]
#       foo
nothing added to commit but untracked files present (use "git add" to track)
$
    
42
2012-12-21 22: 14: 31Z

Esta es una forma de evitar este problema desconcertante al iniciar un nuevo proyecto:

  • Cree el directorio principal para su nuevo proyecto.
  • Ejecutar git init.
  • Ahora crea un archivo .gitignore (incluso si está vacío).
  • Confirma tu archivo .gitignore.

Git hace que sea muy difícil hacer git reset si no tienes ningún commit. Si creas un pequeño compromiso inicial solo por tener uno, después de eso puedes git add -A y git reset tantas veces como quieras para que todo salga bien.

Otra ventaja de este método es que si te topas con problemas de final de línea más tarde y necesitas actualizar todos tus archivos, es fácil:

  • Echa un vistazo a ese compromiso inicial. Esto eliminará todos tus archivos.
  • Luego revisa tu confirmación más reciente otra vez. Esto recuperará copias nuevas de sus archivos, usando su configuración de final de línea actual.
37
2012-05-10 18: 59: 01Z
  1. ¡Confirmado! Intenté reiniciar git después de añadir git. y Git se quejaba de la CABEZA corrupta. Siguiendo tu consejo, podría agregar & restablecer de ida y vuelta sin problemas :)
    2012-10-03 21: 32: 16Z
  2. La segunda parte funciona, pero es un poco torpe. Cómo se manejan los finales de línea, depende del valor autocrlf ... Esto no funcionará en todos los proyectos, dependiendo de la configuración.
    2013-03-29 11: 26: 58Z
  3. Esta respuesta fue razonable en el momento de su publicación, pero ahora está obsoleta; El git reset somefile y el git reset funcionan antes de realizar la primera confirmación, ahora. Este ha sido el caso desde varios lanzamientos de Git.
    2015-10-30 23: 38: 32Z
  4. @ MarkAmery, puede que tengas razón (sería genial si publicaras una fuente para tu afirmación), pero todavía hay valor en comenzar tu repo con un compromiso limpio o dos.
    2015-10-31 20: 01: 14Z

Tal vez Git haya evolucionado desde que publicaste tu pregunta.

 
$> git --version
git version 1.6.2.1

Ahora, puedes probar:

 
git reset HEAD .

Esto debería ser lo que estás buscando.

    
33
2013-03-09 11: 17: 13Z
  1. Claro, pero luego tienes la siguiente pregunta de cómo se debe agregar uno de los dos (o más) archivos agregados. El manual "git reset" menciona que "git reset < paths >" es lo contrario de "git add < paths >", sin embargo.
    2013-05-15 13: 36: 21Z

Tenga en cuenta que si no puede especificar una revisión, debe incluir un separador. Ejemplo desde mi consola:

 
git reset <path_to_file>
fatal: ambiguous argument '<path_to_file>': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

git reset -- <path_to_file>
Unstaged changes after reset:
M   <path_to_file>

(git version 1.7.5.4)

    
33
2014-04-05 05: 32: 50Z
  1. Probé git reset <path> y funciona bien sin un separador. También estoy usando git 1.9.0. Tal vez no funciona en versiones anteriores?
    2014-04-05 05: 32: 25Z

Para eliminar nuevos archivos del área de preparación (y solo en el caso de un nuevo archivo), como se sugirió anteriormente:

 
git rm --cached FILE

Use rm --cached solo para nuevos archivos agregados accidentalmente.

    
30
2009-06-22 19: 46: 28Z
  1. Tenga en cuenta que el --cached es una parte muy importante aquí.
    2013-04-12 12: 21: 46Z
  2. - 1; no, esto no elimina el estado del archivo, realiza una eliminación del archivo (sin eliminarlo realmente de su árbol de trabajo).
    2015-10-30 23: 42: 05Z

Para restablecer cada archivo en una carpeta en particular (y sus subcarpetas), puede usar el siguiente comando:

 
git reset *
    
24
2012-07-26 07: 50: 36Z
  1. En realidad, esto no restablece todos los archivos porque * usa la expansión del shell e ignora los archivos de puntos (y los directorios de puntos).
    2014-05-04 23: 20: 01Z
  2. Puede ejecutar git status para ver lo que queda y restablecerlo manualmente, es decir, git reset file.
    2014-05-07 15: 23: 55Z

use el comando * para manejar múltiples archivos a la vez

 
git reset HEAD *.prj
git reset HEAD *.bmp
git reset HEAD *gdb*

etc

    
24
2013-08-27 21: 15: 05Z
  1. Tenga en cuenta que * generalmente no incluirá archivos de puntos o 'directorios de puntos' a menos que especifique explícitamente .* o .*.prj
    2014-05-04 23: 21: 06Z

Simplemente escriba git reset, volverá atrás y es como si nunca hubiera escrito git add . desde su último confirmación. Asegúrate de que has cometido antes.

    
22
2015-04-22 10: 57: 19Z
  1. No funcionará si no hay un último commit.
    2012-04-11 22: 07: 03Z
  2. A medida que ocurría, hubo una última confirmación ... pero estaba preguntando específicamente sobre la eliminación de un solo archivo de la confirmación, no todos los archivos de la confirmación.
    2013-01-31 16: 21: 37Z

Supongamos que creo un nuevo archivo newFile.txt.

 introduce la descripción de la imagen aquí

Supongamos que agrego el archivo accidentalmente, git add newFile.txt

 introduce la descripción de la imagen aquí

Ahora quiero deshacer este complemento, antes de confirmar, git reset newFile.txt

 introduce la descripción de la imagen aquí

    
18
2016-10-04 11: 02: 48Z
  1. Supongamos que estoy en la primera imagen que significa que ni siquiera hice "git.add". Además, no quiero en absoluto todo este cambio. Quiero decir que cuando hago el estado de git, no debería mostrar ningún archivo rojo. Quiero decir que debería estar sincronizado como si no hubiera un solo archivo alterado desde el último empujón de git. cómo lograr eso.
    2017-03-26 00: 59: 40Z
  2. ASÍ que suponga que está en el primer paso. Y desea deshacerse de todos los cambios que ha hecho, lo que hace que "newFile.txt" aparezca en rojo.
    2017-03-26 01: 00: 12Z
  3. Cuando hago el estado de git. No debería ver ningún cambio en absoluto. Todos los archivos rojos deberían revertirse.
    2017-03-26 01: 00: 50Z
  4. Hola, creo que tu pregunta es cómo eliminar archivos sin seguimiento del árbol actual. Para eso, puedes usar "git clean -f -d". Esto también eliminará los directorios sin seguimiento.
    2017-03-26 10: 19: 04Z
  5. Si no desea eliminar los archivos sin seguimiento, simplemente ignore la bandera "-f".
    2017-03-26 10: 20: 26Z

Para un archivo específico:

  
  • git reset my_file.txt
  •   
  • git checkout my_file.txt
  •   

Para todos los archivos agregados:

  
  • git reset.
  •   
  • git checkout.
  •   

Nota: checkout cambia el código en los archivos y pasa al último estado actualizado (confirmado). restablecer no cambia los códigos; simplemente restablece el encabezado.

    
17
2018-09-28 18: 11: 49Z
  1. Explique la diferencia entre git reset <file> y git checkout <file>.
    2018-01-22 23: 47: 24Z
  2. reset no cambia el archivo, simplemente póngalo fuera del escenario (= índice, donde fue puesto por gitañadir)
    2018-03-12 11: 18: 32Z
  3. checkout cambia los códigos en el archivo y pasa al último estado actualizado. restablecer no cambia los códigos, simplemente restablece el encabezado. Como ejemplo, reinicie el uso para los archivos agregados o confirmados, reinicie el uso antes de enviar y enviar para volver a la última etapa actualizada /confirmada antes de agregar git.
    2018-03-14 11: 38: 53Z
  4. reset = eliminar el archivo de la etapa, sin embargo, los cambios seguirán existiendo. checkout = obtiene el archivo actualizado del repositorio y anulará el archivo actual
    2018-09-12 10: 16: 22Z

Este comando deshará tus cambios:

 
git reset HEAD filename.txt

También puedes usar

 
git add -p 

para agregar partes de archivos.

    
13
2013-03-09 11: 22: 31Z

Me sorprende que nadie mencione el modo interactivo:

 
git add -i

elija la opción 3 para anular la adición de archivos. En mi caso, a menudo quiero agregar más de un archivo, con el modo interactivo puedes usar números como este para agregar archivos. Esto tomará todos menos 4: 1,2,3,5

Para elegir una secuencia, simplemente escribe 1-5 para tomar todo de 1 a 5.

archivos de preparación de Git

    
13
2015-10-26 12: 20: 07Z
  1. "Me sorprende que nadie mencione el modo interactivo" : lo hicieron: stackoverflow.com/a/10209776/1709587
    2015-10-30 23: 52: 13Z

Para deshacer git add use

git reset filename

    
13
2016-10-02 15: 54: 48Z
 
git reset filename.txt

Eliminará un archivo llamado filename.txt del índice actual, el área "a punto de comprometerse", sin cambiar nada más.

    
9
2016-07-11 18: 40: 52Z

git add myfile.txt # esto agregará su archivo a la lista confirmada

Muy al contrario de este comando es,

 
git reset HEAD myfile.txt  # this will undo it. 

entonces, estarás en el estado anterior. especificado volverá a estar en la lista sin seguimiento (estado anterior).

restablecerá tu cabeza con ese archivo especificado. así que, si tu cabeza no lo tiene, significa que simplemente lo restablecerá

    
9
2017-06-27 13: 58: 34Z

En SourceTree puedes hacerlo fácilmente a través de la interfaz gráfica de usuario. Puede verificar qué comando usa sourcetree para desestabilizar un archivo.

Creé un nuevo archivo y lo agregué a git. Luego lo desestabilizé usando la interfaz gráfica de SourceTree. Este es el resultado:

  

Archivos sin etapas [12/08/15 10:43]
  git -c diff.mnemonicprefix = false -c core.quotepath = false -c credential.helper = sourcetree reset -q - ruta /a /archivo /filename.java

SourceTree usa reset para descomponer nuevos archivos.

    
8
2015-12-08 09: 58: 33Z

Una de las soluciones más intuitivas es utilizar SourceTree .

Usted puede simplemente arrastrar y soltar archivos desde etapas y no etapas ingrese la descripción de la imagen aquí

    
7
2017-05-26 08: 32: 16Z
fuente colocada aquí