9286 votes

Annuler la commande git add " avant de s'engager

Je rajoutait des fichiers à l'aide de la commande

git add file

J'ai pas encore exécuté git commit. Est-il un moyen d'annuler cette ou supprimer ces fichiers à partir de la validation?

10831voto

genehack Points 26851

Vous pouvez également

git reset <file>

lequel sera retiré de l'indice actuel (le "sur le point d'être commis") sans rien changer d'autre. Notez que git reset <file> "est l'abréviation de git reset HEAD <file>.

Vous pouvez utiliser git reset sans aucun nom de fichier pour annuler toutes les modifications. Cela peut être pratique quand il y a trop de fichiers à être énumérés un par un.

2187voto

Rhubarb Points 16453

Vous souhaitez:

git rm --cached <added_file_to_undo>

Raisonnement:

Quand j'étais nouveau à cela, j'ai d'abord essayé

git reset .

(pour annuler ma toute première extension), seulement pour obtenir ce (pas si) utiles message:

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

Il s'avère que c'est parce que la TÊTE ref (branche?) n'existe pas jusqu'à ce que après la première validation. Qui est, vous tomberez dans le même débutant problème que moi si votre flux de travail, comme la mienne, était quelque chose comme:

  1. cd à ma grande nouvelle répertoire de projet pour essayer de Git, le nouveau hotness
  2. git init
  3. git add .
  4. git status

    ... des tas de merde défile en ...

    => Merde, je ne voulais pas ajouter à tout cela.

  5. google "annuler la commande git add"

    => trouver un Débordement de Pile - yay

  6. git reset .

    => fatal: impossible de résoudre "TÊTE" comme valide réf.

Il s'avère qu'il y a un bug connecté à l'encontre de la unhelpfulness de cette dans la liste de diffusion.

Et que la bonne solution était là, dans le Git status de sortie (qui, oui, j'ai écarté comme " de la merde)

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

Et la solution est en effet d'utiliser git rm --cached FILE.

Remarque les mises en garde d'ailleurs ici - git rm supprime votre copie de travail locale du fichier, mais pas si vous utilisez --mis en cache. Voici le résultat d' git help rm:

--mise en cache Utilisez cette option pour unstage et de supprimer les chemins de l'index. De travail de l'arborescence de fichiers, modifiés ou non, sera à gauche.

- Je procéder pour l'utiliser

git rm --cached .

pour tout supprimer et recommencer. Ne fonctionne pas bien, parce qu' add . est récursive, s'avère rm besoins -r répéter. Soupir.

git rm -r --cached .

Bon, maintenant je suis de retour là où j'ai commencé. La prochaine fois, je vais utiliser -n de faire un essai et voir ce qui va être ajouté:

git add -n .

J'ai zippé le tout à un endroit sûr avant d'approuver git help rm sur le --cached ne pas détruire quoi que ce soit (et si j'ai mal orthographié).

541voto

Paul Beckingham Points 7460

Si vous tapez:

git status

git vous dira ce qui est mis en scène, etc, y compris des instructions sur la façon d'unstage:

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

Je trouve git fait un assez bon travail de me pousser à faire la bonne chose dans ce genre de situation.

Remarque: les Dernières versions git (1.8.4.x) a changé de ce message:

(use "git rm --cached <file>..." to unstage)

253voto

takeshin Points 16579

Pour clarifier: git add se déplace modifications à partir du répertoire de travail en cours de la zone de transit (index).

Ce processus est appelé la mise en scène. Donc, le plus naturel de commande à l' étape de l'changements (fichiers modifiés) est le plus évident:

git stage

git add est juste un plus facile de type alias git stage

Dommage il n'y a pas d' git unstage ni git unadd des commandes. L'un est plus difficile à deviner ou à se rappeler, mais il est assez évident:

git reset HEAD --

Nous pouvons facilement créer un alias pour ce:

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

Et enfin, nous avons de nouvelles commandes:

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

Personnellement, j'utilise même les plus courts alias:

git a #for staging
git u #for unstaging

172voto

leonbloy Points 27119

Un plus pour la accepté réponse: si votre rajoutait fichier a été énorme, vous aurez probablement remarqué que, même après la suppression de l'index 'git reset', il semble toujours à occuper l'espace dans l' .git répertoire. Ce n'est rien à être inquiet, le fichier est en effet toujours dans le référentiel, mais seulement comme un "lâche l'objet", il ne pourra être copié sur d'autres référentiels (via clone, pousser), et l'espace sera finalement récupéré - mais peut-être pas pour très bientôt. Si vous êtes impatient, vous pouvez exécuter:

git gc --prune=now

Mise à jour (ce qui suit est une tentative de ma part pour effacer une certaine confusion qui peut résulter de la plupart des upvoted réponses):

Alors, qui de la followint est le réel annulation de l' git add?

git reset HEAD <file> ?

git rm --cached <file>?

À strictement parler, et si je ne me trompe pas: aucun. git add ne peut pas être annulée , en toute sécurité, en général.

Rappelons d'abord ce qu' git add <file> ne fait:

  1. Si <file> était précédemment pas suivi, git add ajoute à la cache, avec son contenu actuel.

  2. Si <file> a été déjà suivis, git add enregistre le contenu actuel (instantané, version) pour le cache. Dans GIT, cette action est appelée encore ajouter, (et non la simple mise à jour ), parce que deux versions différentes (captures d'écran) d'un fichier sont considérés comme deux éléments différents: par conséquent, nous sommes en effet de l'ajout d'un nouvel élément dans le cache, pour être finalement engagé plus tard.

Dans ce contexte, la question est un peu ambiguë:

Je rajoutait des fichiers à l'aide de la commande...

L'OP scénario semble être le premier (sans traces de fichier), nous voulons que le "undo" pour supprimer le fichier (et pas seulement le contenu actuel) à partir du suivi des articles. Si c'est le cas, alors c'est ok pour exécuter git rm --cached <file>.

Et nous avons aussi pu exécuter git reset HEAD <file>. C'est en général préférable, parce qu'elle fonctionne dans les deux scénarios: il peut aussi annuler lorsque nous avons ajouté une version d'un suivi de l'élément.

Mais il y a deux mises en garde.

La première: Il y a (comme indiqué dans la réponse), un seul scénario dans lequel, git reset HEAD ne fonctionne pas, mais git rm --cached fait: un nouveau référentiel (non valide). Mais, vraiment, c'est un infondée cas.

Deuxièmement: Être conscient qu' git reset HEAD peut pas comme par magie récupérer le déjà mis en cache le contenu du fichier, c'est juste resyncs de la TÊTE. Si notre erronées git add a remplacé une précédente mise en scène uncommited version, nous ne pouvons pas le récupérer. C'est pourquoi, à proprement parler, nous ne pouvons pas annuler.

Exemple:

$ 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

Bien sûr, ce n'est pas très critique si nous suivons juste l'habitude paresseuse de flux de travail de faire "git add" uniquement pour l'ajout de nouveaux fichiers (cas 1), et nous mettre à jour de nouveaux contenus par l'intermédiaire de la commettre, en git commit -a commande.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X