Parfois, git suggère git rm --cachedde supprimer un fichier, parfois git reset HEAD file. Quand devrais-je utiliser quoi?

ÉDITER:

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> ne supprime pas un fichier, il effectue en fait la suppression du ou des fichiers du référentiel (en supposant qu'il a déjà été validé auparavant) mais laisse le fichier dans votre arborescence de travail (vous laissant avec un fichier non suivi).

git reset -- <filePath>se désindexer tout mis en scène les modifications du fichier donné (s).

Cela dit, si vous avez utilisé git rm --cachedun nouveau fichier qui est mis en scène, il semblerait que vous veniez de le décompresser, car il n'avait jamais été validé auparavant.

Mettre à jour git 2.24
Dans cette nouvelle version de git, vous pouvez utiliser à la git restore --stagedplace de git reset. Voir git docs .

git rm --cachedest utilisé pour supprimer un fichier de l'index. Dans le cas où le fichier est déjà dans le référentiel, git rm --cachedsupprimera le fichier de l'index, le laissant dans le répertoire de travail et un commit le supprimera désormais également du référentiel. Fondamentalement, après la validation, vous auriez annulé la version du fichier et conservé une copie locale.

git reset HEAD file(qui par défaut utilise l' --mixedindicateur) est différent en ce que dans le cas où le fichier est déjà dans le référentiel, il remplace la version d'index du fichier par celle du référentiel (HEAD), supprimant efficacement les modifications qui y sont apportées .

Dans le cas d'un fichier non versionné, il va décompresser le fichier entier car le fichier n'était pas là dans le HEAD. Dans cet aspect git reset HEAD fileet git rm --cachedsont les mêmes, mais ils ne sont pas identiques (comme expliqué dans le cas des fichiers déjà dans le repo)

À la question de Why are there 2 ways to unstage a file in git?- il n'y a jamais vraiment qu'une seule façon de faire quoi que ce soit dans git. c'est ça la beauté :)

Tout simplement:

• git rm --cached <file> fait que git arrête de suivre complètement le fichier (le laissant dans le système de fichiers, contrairement à plain git rm*)
• git reset HEAD <file> annule toutes les modifications apportées au fichier depuis le dernier commit (mais ne les annule pas dans le système de fichiers, contrairement à ce que le nom de la commande pourrait suggérer **). Le fichier reste sous contrôle de révision.

Si le fichier n'était pas sous contrôle de révision auparavant (c'est-à-dire que vous supprimez un fichier que vous venez de modifier git addpour la première fois), alors les deux commandes ont le même effet, d'où l'apparence de ces deux façons de faire quelque chose. ".

_{* Gardez à l'esprit la mise en garde mentionnée par @DrewT dans sa réponse, concernant git rm --cachedun fichier qui a été précédemment validé dans le référentiel. Dans le cadre de cette question, d'un fichier qui vient d'être ajouté et non encore validé, il n'y a rien à craindre.}

_{** J'ai eu peur pendant une longue période embarrassante d'utiliser la commande git reset à cause de son nom - et aujourd'hui encore je recherche souvent la syntaxe pour m'assurer de ne pas bousiller. ( mise à jour : j'ai finalement pris le temps de résumer l'utilisation de git resetdans une page tldr , donc maintenant j'ai un meilleur modèle mental de la façon dont cela fonctionne, et une référence rapide pour quand j'oublie certains détails.)}

Ce fil est un peu ancien, mais je veux quand même ajouter une petite démonstration car ce n'est toujours pas un problème intuitif:

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(sans -q) donne un avertissement sur le fichier modifié et son code de sortie est 1 qui sera considéré comme une erreur dans un script.

Modifier: git checkout HEAD to-be-modified to-be-removedfonctionne également pour la suppression de la mise en scène, mais supprime complètement la modification de l'espace de travail

Mise à jour de git 2.23.0: De temps en temps, les commandes changent. Maintenant, git statusdit:

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

... qui fonctionne pour les trois types de changement

si vous avez accidentellement organisé des fichiers que vous ne souhaitez pas valider et que vous souhaitez être certain de conserver les modifications, vous pouvez également utiliser:

git stash
git stash pop

cela effectue une réinitialisation de HEAD et réapplique vos modifications, vous permettant de recréer les fichiers individuels pour validation. cela est également utile si vous avez oublié de créer une branche de fonctionnalité pour les demandes d'extraction ( git stash ; git checkout -b <feature> ; git stash pop).

Ces 2 commandes ont plusieurs différences subtiles si le fichier en question est déjà dans le repo et sous contrôle de version (précédemment validé etc.):

• git reset HEAD <file> décompresse le fichier dans le commit en cours.
• git rm --cached <file>décompactera également le fichier pour les futures validations. Il n'est pas mis en scène jusqu'à ce qu'il soit à nouveau ajouté avecgit add <file> .

Et il y a une autre différence importante:

• Après avoir exécuté git rm --cached <file>et poussé votre branche vers la télécommande, toute personne tirant votre branche de la télécommande verra le fichier réellement supprimé de son dossier, même si dans votre jeu de travail local, le fichier n'est plus suivi (c'est-à-dire qu'il n'est pas physiquement supprimé du dossier).

Cette dernière différence est importante pour les projets qui incluent un fichier de configuration où chaque développeur de l'équipe a une configuration différente (c'est-à-dire une URL de base, une adresse IP ou un paramètre de port différents), donc si vous utilisez git rm --cached <file>quelqu'un qui tire votre branche, vous devrez manuellement créez la configuration, ou vous pouvez leur envoyer la vôtre et ils peuvent la rééditer dans leurs paramètres IP (etc.), car la suppression n'effectue que les personnes tirant votre branche de la télécommande.

Disons que vous avez stageun répertoire entier via git add <folder>, mais vous voulez exclure un fichier de la liste intermédiaire (c'est-à-dire la liste qui se génère lors de l'exécution git status) et conserver les modifications dans le fichier exclu (vous travailliez sur quelque chose et il n'est pas prêt pour la validation, mais vous ne voulez pas perdre votre travail ...). Vous pouvez simplement utiliser:

git reset <file>

Lorsque vous exécutez git status, vous verrez que les fichiers que vous resetêtes unstagedet le reste des fichiers addedsont toujours dans la stagedliste.

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

(utilisez "git rm --cached ..." pour mettre en scène)

• git est un système de pointeurs

• vous n'avez pas encore de commit pour changer votre pointeur en

• la seule façon de `` retirer des fichiers du seau pointé '' est de supprimer les fichiers auxquels vous avez demandé à git de surveiller les changements

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

• vous vous êtes engagé, " enregistré »

3.

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

(utilisez "git reset HEAD ..." pour mettre en scène)

• vous avez fait un commit dans votre code à ce moment
• vous pouvez maintenant réinitialiser votre pointeur sur votre commit " revenir à la dernière sauvegarde "

Je suis surpris que personne n'ait mentionné le git reflog ( http://git-scm.com/docs/git-reflog ):

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

Le reflog est un historique git qui non seulement suit les modifications apportées au référentiel, mais également les actions de l'utilisateur (par exemple, tirer, extraire une branche différente, etc.) et permet d'annuler ces actions. Ainsi, au lieu de supprimer la mise en scène du fichier qui a été mal organisé, vous pouvez revenir au point où vous n'avez pas mis en scène les fichiers.

Ceci est similaire git reset HEAD <file>mais peut dans certains cas être plus granuleux.

Désolé - ne répond pas vraiment à votre question, mais indique simplement une autre façon de décompresser les fichiers que j'utilise assez souvent (pour ma part, j'aime beaucoup les réponses de Ryan Stewart et waldyrious.);) J'espère que cela aide.

Utilisez simplement:

git reset HEAD <filename>

Cela décompose le fichier et conserve les modifications que vous y avez apportées, vous pouvez donc, à son tour, modifier les branches si vous le souhaitez et git addces fichiers à la place d'une autre branche. Toutes les modifications sont conservées.

Il me semble que git rm --cached <file>le fichier est supprimé de l'index sans le supprimer du répertoire où un simple git rm <file>ferait les deux, tout comme un système d'exploitation rm <file>supprimerait le fichier du répertoire sans supprimer sa version.

Pour les versions 2.23 et supérieures uniquement,

Au lieu de ces suggestions, vous pouvez utiliser git restore --staged <file>pour unstagele (s) fichier (s).