«Git rm --cached x» vs «git reset head - x»?

GitRef.org - Basique :

git rmsupprimera les entrées de la zone de transit. C'est un peu différent de git reset HEADcelui des fichiers "désétapes". Par "unstage", je veux dire que cela ramène la zone de préparation à ce qui était là avant que nous commencions à modifier les choses. git rmd'un autre côté, il suffit de lancer complètement le fichier de la scène, de sorte qu'il ne soit pas inclus dans l'instantané de validation suivant, le supprimant ainsi efficacement.

Par défaut, a git rm filesupprimera entièrement le fichier de la zone de préparation et également de votre disque> (le répertoire de travail). Pour laisser le fichier dans le répertoire de travail, vous pouvez utiliser git rm --cached.

Mais quelle est exactement la différence entre git rm --cached asdet git reset head -- asd?

Il y a trois endroits où un fichier, par exemple, peut être - l'arborescence, l'index et la copie de travail. Lorsque vous ajoutez simplement un fichier à un dossier, vous l'ajoutez à la copie de travail.

Lorsque vous faites quelque chose comme git add filevous l'ajoutez à l'index. Et lorsque vous le validez, vous l'ajoutez également à l'arbre.

Cela vous aidera probablement à connaître les trois indicateurs les plus courants dans git reset:

git reset [- <mode>] [ <commit>]

Ce formulaire réinitialise la tête de branche actuelle <commit>et met éventuellement à jour l'index (en le réinitialisant dans l'arborescence de <commit>) et l'arbre de travail en fonction de <mode>, qui doit être l'un des suivants:
--soft

Ne touche pas du tout le fichier d'index ni l'arborescence de travail (mais réinitialise la tête sur <commit>, comme tous les modes le font). Cela laisse tous vos fichiers modifiés "Modifications à valider", comme le dirait l'état git.

--mixte

Réinitialise l'index mais pas l'arborescence de travail (c'est-à-dire que les fichiers modifiés sont conservés mais pas marqués pour la validation) et signale ce qui n'a pas été mis à jour. C'est l'action par défaut.

--dur

Réinitialise l'index et l'arborescence de travail. Toutes les modifications apportées aux fichiers suivis dans l'arborescence de travail depuis <commit>sont ignorées.

Maintenant, quand vous faites quelque chose comme git reset HEAD- ce que vous faites réellement est git reset HEAD --mixedet cela "réinitialise" l'index à l'état où il était avant de commencer à ajouter des fichiers / ajouter des modifications à l'index (via git add) Dans ce cas, la copie de travail et le index (ou staging) étaient synchronisés, mais vous avez fait en sorte que HEAD et l'index soient synchronisés après la réinitialisation.

git rmd'autre part, supprime un fichier du répertoire de travail et de l'index et lorsque vous validez, le fichier est également supprimé de l'arborescence. git rm --cachedcependant supprime le fichier de l'index seul et le conserve dans votre copie de travail. C'est exactement le contraire de git add file Dans ce cas, vous avez fait que l'index soit différent de la tête et du travail, en ce que la tête a la version précédemment validée du fichier, la copie de travail a eu la dernière modification, le cas échéant, ou le contenu de HEAD de le fichier et vous avez supprimé le fichier de l'index. Un commit maintenant synchronisera l'index et l'arborescence et le fichier sera supprimé.

Peut-être qu'un exemple vous aidera:

git rm --cached asd
git commit -m "the file asd is gone from the repository"

contre

git reset HEAD -- asd
git commit -m "the file asd remains in the repository"

Notez que si vous n'avez rien changé d' autre , le deuxième commit ne fera rien.

git rm --cached fileva supprimer le fichier de la scène. Autrement dit, lorsque vous validez, le fichier sera supprimé. git reset HEAD -- fileréinitialisera simplement le fichier dans la zone de préparation à l'état où il était lors de la validation HEAD, c'est-à-dire annulera toutes les modifications que vous y avez apportées depuis la dernière validation. Si ce changement vient d'ajouter le fichier, alors ils seront équivalents.