Après le dernier commit, j'ai modifié un tas de fichiers dans ma copie de travail, mais je veux annuler les modifications apportées à l'un de ces fichiers, comme pour le réinitialiser au même état que le commit le plus récent.
Cependant, je veux seulement annuler les modifications de copie de travail de ce seul fichier, rien d'autre avec lui.
Comment je fais ça?
Réponses:
Vous pouvez utiliser
git checkout -- file
Vous pouvez le faire sans --(comme suggéré par nimrodm), mais si le nom de fichier ressemble à une branche ou à une balise (ou à un autre identifiant de révision), il peut devenir confus, il --est donc préférable d' utiliser .
Vous pouvez également consulter une version particulière d'un fichier:
git checkout v1.2.3 -- file # tag v1.2.3
git checkout stable -- file # stable branch
git checkout origin/master -- file # upstream master
git checkout HEAD -- file # the version from the most recent commit
git checkout HEAD^ -- file # the version before the most recent commit
git reset HEAD <filename> ; git checkout -- <filename>
HEAD^^pour 2 validations à partir de la plus récente, ou HEAD^^^pour 3 validations de retour. Vous pouvez également utiliser HEAD~2, ou HEAD~3, ce qui devient plus pratique si vous souhaitez revenir en arrière, tandis que HEAD^2signifie "le deuxième parent de cette validation"; en raison des validations de fusion, une validation peut avoir plusieurs validations précédentes, donc avec HEAD^un nombre sélectionne lequel de ces parents, tandis qu'avec HEAD~un nombre sélectionne toujours le premier parent mais ce nombre de validations revient. Voir git help rev-parsepour plus de détails.
Utilisez simplement
git checkout filename
Cela remplacera le nom de fichier par la dernière version de la branche actuelle.
AVERTISSEMENT: vos modifications seront annulées - aucune sauvegarde n'est conservée.
git checkout xet x se trouve être un nom de branche ainsi qu'un nom de fichier, je ne sais pas quel est le comportement par défaut mais je pense que git supposera que vous voulez passer à la branche x. Lorsque vous utilisez, --vous dites que ce qui suit est un ou plusieurs noms de fichier.
--. Bien que toujours correct, comme le souligne @hasen, s'il y a une ambiguïté entre le nom de fichier et les noms de branche, vous pouvez vous retrouver avec un comportement très indésirable ici!
--, agréable et facile. Lorsque vous nommez des branches en utilisant des noms de fichiers, il doit y avoir une mauvaise pensée quelque part ...
git checkout <commit> <filename>
Je l'ai utilisé aujourd'hui car j'ai réalisé que mon favicon avait été écrasé il y a quelques commits il y a quelques temps lorsque je suis passé à la version drupal 6.10, j'ai donc dû le récupérer. Voici ce que j'ai fait:
git checkout 088ecd favicon.ico
git log --oneline <filename>vous donnera un journal plus compact et n'inclura que les modifications apportées au fichier spécifique
git reflog <filename>
Si votre fichier est déjà mis en scène (se produit lorsque vous effectuez un ajout de git, etc. après la modification du fichier) pour annuler les modifications.
Utilisation
git reset HEAD <file>
alors
git checkout <file>
Si ce n'est déjà fait, utilisez simplement
git checkout <file>
Si vous souhaitez simplement annuler les modifications du commit précédent sur ce fichier, vous pouvez essayer ceci:
git checkout branchname^ filename
Cela extraira le fichier tel qu'il était avant le dernier commit. Si vous souhaitez revenir en arrière quelques fois, utilisez la branchname~nnotation.
branchname^
Je suis toujours confus avec cela, voici donc un cas de test de rappel; disons que nous avons ce bashscript à tester git:
set -x
rm -rf test
mkdir test
cd test
git init
git config user.name test
git config user.email test@test.com
echo 1 > a.txt
echo 1 > b.txt
git add *
git commit -m "initial commit"
echo 2 >> b.txt
git add b.txt
git commit -m "second commit"
echo 3 >> b.txt
À ce stade, la modification n'est pas mise en scène dans le cache, tout git statuscomme:
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: b.txt
no changes added to commit (use "git add" and/or "git commit -a")
Si à partir de ce point, nous le faisons git checkout, le résultat est le suivant:
$ git checkout HEAD -- b.txt
$ git status
On branch master
nothing to commit, working directory clean
Si au contraire nous le faisons git reset, le résultat est:
$ git reset HEAD -- b.txt
Unstaged changes after reset:
M b.txt
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: b.txt
no changes added to commit (use "git add" and/or "git commit -a")
Donc, dans ce cas - si les modifications ne sont pas échelonnées, git resetcela ne fait aucune différence, tout en git checkoutécrasant les modifications.
Maintenant, disons que le dernier changement par rapport au script ci-dessus est mis en scène / mis en cache, c'est-à-dire que nous l'avons également fait git add b.txtà la fin.
Dans ce cas, git statusà ce stade est:
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: b.txt
Si à partir de ce point, nous le faisons git checkout, le résultat est le suivant:
$ git checkout HEAD -- b.txt
$ git status
On branch master
nothing to commit, working directory clean
Si au contraire nous le faisons git reset, le résultat est:
$ git reset HEAD -- b.txt
Unstaged changes after reset:
M b.txt
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: b.txt
no changes added to commit (use "git add" and/or "git commit -a")
Donc, dans ce cas - si les modifications sont échelonnées, elles git resetferont essentiellement des changements échelonnés en changements non échelonnés - alors qu'elles git checkoutécraseront complètement les changements.
Cette réponse concerne la commande nécessaire pour annuler les modifications locales qui se trouvent dans plusieurs fichiers spécifiques dans le même ou plusieurs dossiers (ou répertoires). Cette réponse répond spécifiquement à la question où un utilisateur a plus d'un fichier mais l'utilisateur ne veut pas annuler toutes les modifications locales:
si vous avez un ou plusieurs fichiers, vous pouvez appliquer la même commande (
git checkout -- file) à chacun de ces fichiers en répertoriant chacun de leur emplacement séparé par un espace comme dans:
git checkout -- name1/name2/fileOne.ext nameA/subFolder/fileTwo.ext
attention à l'espace ci-dessus entre nom1 / nom2 / fileOne.ext nomA / subFolder / fileTwo.ext
Pour plusieurs fichiers dans le même dossier:
Si vous devez annuler les modifications de tous les fichiers d'un certain répertoire, utilisez la vérification git comme suit:
git checkout -- name1/name2/*
L'astérisque ci-dessus fait l'affaire de l'annulation de tous les fichiers à cet emplacement sous nom1 / nom2.
De même, les éléments suivants peuvent annuler les modifications dans tous les fichiers pour plusieurs dossiers:
git checkout -- name1/name2/* nameA/subFolder/*
attention encore à l'espace entre nom1 / nom2 / * nomA / sous-dossier / * dans ce qui précède.
Remarque: nom1, nom2, nomA, sous-dossier - tous ces exemples de noms de dossier indiquent le dossier ou le package dans lequel le ou les fichiers en question peuvent résider.
Pour moi, seul celui-ci a fonctionné
git checkout -p filename
Si vous n'avez pas encore poussé ou partagé votre commit:
git diff --stat HEAD^...HEAD | \
fgrep filename_snippet_to_revert | cut -d' ' -f2 | xargs git checkout HEAD^ --
git commit -a --amend
