IP Girl
  1. IP Girl
  3. “Git rc –cached x” vs “git reset head – x”?
Intereting Posts
Erreur: le service n’est pas valide Récupérer uniquement les champs statiques déclarés dans la classe Java docker ne peut pas se connecter à boot2docker en raison du délai d’attente TCP Comment lire cette «preuve» GHC Core? Division sans utiliser ‘/’ Hexadécimal à décimal dans le script shell Comment faire pour que Visual Studio ouvre la fenêtre Resolve Conflicts après un Get TFS Pourquoi utiliser un ReentrantLock si on peut utiliser synchronisé (this)? Où puis-je trouver WcfTestClient.exe (partie de Visual Studio) Git diff en HTML Problème Rails 4 favicon HttpContext.Current.Session est null lors du routage des requêtes Déterminer la version d’Entity Framework que j’utilise? Comment augmenter la valeur d’un nombre au multiple suivant de 10, 100, 1000, 10 000 et ainsi de suite Comment attend-on le travail asynchrone en C #

“Git rc –cached x” vs “git reset head – x”?

GitRef.org – Basique :

git rm supprimera les entrées de la zone de transit. C’est un peu différent de git reset HEAD qui “décompose” les fichiers. Par “unstage”, je veux dire qu’il ramène la zone de mise en scène à ce qui existait avant de commencer à modifier les choses. git rm désactive complètement le fichier, de sorte qu’il ne soit pas inclus dans le prochain snapshot de validation, le supprimant ainsi.

Par défaut, un git rm file supprime complètement le fichier de la zone de transfert 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 asd et 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 file vous l’ajoutez à l’index. Et lorsque vous le validez, vous l’ajoutez également à l’arbre.

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

git reset [- ] [ ]

Ce formulaire réinitialise l’en-tête actuel de la twig à et met éventuellement à jour l’index (en le réinitialisant à l’arbre de ) et l’arborescence de travail en fonction de , qui doit être l’un des suivants:
–doux

Ne touche pas le fichier d’index ni l’arborescence de travail (mais réinitialise la tête à , comme tous les modes). Cela laisse tous vos fichiers modifiés “Modifications à commettre”, comme le mettrait git status.

–mixte

Réinitialise l’index mais pas l’arborescence de travail (c.-à-d. Que les fichiers modifiés sont préservés mais ne sont pas marqués pour la validation) et rapporte ce qui n’a pas été mis à jour. C’est l’action par défaut.

–difficile

Réinitialise l’index et l’arborescence de travail. Toute modification apscope aux fichiers suivis dans l’arborescence de travail depuis que est supprimée.

Maintenant, lorsque vous faites quelque chose comme git reset HEAD – ce que vous êtes en train de faire est git reset HEAD --mixed et il “réinitialisera” l’index à l’état où il se trouvait avant d’append des fichiers / append des modifications à l’index (via git add ) Dans ce cas, la copie de travail et l’index (ou la mise en attente) étaient synchronisés, mais vous avez synchronisé HEAD et l’index après la réinitialisation.

git rm revanche, git rm supprime un fichier du répertoire de travail et de l’index et lorsque vous le validez, le fichier est également supprimé de l’arborescence. git rm --cached supprime cependant 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 en sorte que l’index soit différent de HEAD et du travail, dans lequel le HEAD a la version précédemment validée du fichier, la copie de travail avait la modification las s’il y en avait ou le contenu de HEAD du fichier et vous avez supprimé le fichier de l’index. Un commit maintenant synchronisera l’index et l’arborescence et le fichier sera supprimé.

Un exemple aidera peut-être: 

 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é, le deuxième commit ne fera rien.

git rm --cached file supprime le fichier de la scène. C’est-à-dire que lorsque vous validez le fichier sera supprimé. git reset HEAD -- file réinitialisera simplement le fichier dans la zone de transfert à l’état où il se trouvait sur la validation HEAD, c’est-à-dire qu’il annulera toutes les modifications que vous lui avez apscopes depuis la dernière validation. Si ce changement arrive à append le fichier, ils seront alors équivalents.