Comment est-ce que je rejette les changements non planifiés dans Git?

Comment ignorer les modifications de ma copie de travail qui ne figurent pas dans l’index?

Un autre moyen plus rapide est:

 git stash save --keep-index 

Incluez --include-untracked si vous voulez être complet à ce sujet.

Après cela, vous pouvez supprimer ce cache avec une commande de git stash drop si vous le souhaitez.

Pour tous les fichiers non-créés, utilisez:

 git checkout -- . 

Pour un fichier spécifique, utilisez:

 git checkout path/to/file/to/revert 

Assurez-vous d’inclure la période à la fin.

Il semble que la solution complète soit:

 git clean -df git checkout -- . 

git clean supprime tous les fichiers non suivis (attention: s’il ne supprime pas les fichiers ignorés mentionnés directement dans .gitignore, il peut supprimer les fichiers ignorés résidant dans les dossiers ) et git checkout supprime tous les changements non planifiés.

Ceci extrait l’index actuel du répertoire en cours, en supprimant toutes les modifications des fichiers du répertoire en cours.

 git checkout . 

ou ce qui extrait tous les fichiers de l’index, en écrasant les fichiers de l’arborescence de travail.

 git checkout-index -a -f 
 git clean -df 

Nettoie l’arborescence en supprimant de manière récursive les fichiers qui ne sont pas sous contrôle de version, à partir du répertoire en cours.

-d : supprime les répertoires non suivis en plus des fichiers non suivis

-f : Force (peut ne pas être nécessaire en fonction du paramètre clean.requireForce )

Exécuter git help clean pour voir le manuel

Mon favori est

 git checkout -p 

Cela vous permet de rétablir sélectivement les morceaux.

Voir également:

 git add -p 

Comme aucune réponse ne suggère la combinaison d’option exacte que j’utilise, la voici:

 git clean -dfx git checkout . 

Voici le texte d’aide en ligne pour les options git clean utilisées:

-d

Supprimez les répertoires non suivis en plus des fichiers non suivis. Si un répertoire non suivi est géré par un référentiel Git différent, il n’est pas supprimé par défaut. Utilisez l’option -f deux fois si vous voulez vraiment supprimer un tel répertoire.

-f

Si la variable de configuration Git clean.requireForce n’est pas définie sur false , Git clean refusera de supprimer des fichiers ou des répertoires, à moins d’indiquer -f , -n ou -i . Git refusera de supprimer des répertoires dans le sous-répertoire ou fichier .git , sauf si un second -f est donné.

-x

N’utilisez pas les règles ignore de .gitignore (par répertoire) et $GIT_DIR/info/exclude , mais utilisez toujours les règles ignore avec les options -e . Cela permet de supprimer tous les fichiers non suivis, y compris les produits de construction. Cela peut être utilisé (éventuellement en conjonction avec git reset ) pour créer un répertoire de travail vierge pour tester une version propre.

En outre, git checkout . doit être fait à la racine du repo.

J’ai vraiment trouvé cet article utile pour expliquer quand utiliser quelle commande: http://www.szakmeister.net/blog/2011/oct/12/reverting-changes-git/

Il y a deux cas différents:

  1. Si vous n’avez pas encore organisé le fichier, utilisez la git checkout . Checkout “met à jour les fichiers dans l’arborescence de travail pour correspondre à la version dans l’index”. Si les fichiers n’ont pas été mis en scène (alias ajoutés à l’index) … cette commande va essentiellement ramener les fichiers à ce que votre dernier commit était.

    git checkout -- foo.txt

  2. Si vous avez organisé le fichier, utilisez git reset. Réinitialiser modifie l’index pour correspondre à un commit.

    git reset -- foo.txt

Je soupçonne que l’utilisation de git stash est un choix populaire car c’est un peu moins dangereux. Vous pouvez toujours y revenir si vous en faites trop par mégarde lors de l’utilisation de git reset. La réinitialisation est récursive par défaut.

Consultez l’article ci-dessus pour plus de conseils.

La méthode la plus simple consiste à utiliser cette commande:

Cette commande est utilisée pour ignorer les modifications dans le répertoire de travail –

 git checkout -- . 

https://git-scm.com/docs/git-checkout

Dans la commande git, le stockage des fichiers non suivis est réalisé en utilisant:

 git stash -u 

http://git-scm.com/docs/git-stash

Si vous ne souhaitez pas conserver les modifications non mises en scène (en particulier si les modifications par étapes sont de nouveaux fichiers), j’ai trouvé ceci pratique:

 git diff | git apply --reverse 

Lorsque vous tapez git status, (utilisez “git checkout – …” pour ignorer les modifications dans le répertoire de travail) est affiché.

p.ex. git checkout -- .

git checkout -f


man git-checkout :

-f, --force

Lorsque vous changez de twig, procédez même si l’index ou l’arborescence de travail diffère de HEAD. Ceci est utilisé pour jeter les changements locaux.

Lors de la vérification des chemins de l’index, ne pas échouer sur les entrées non fusionnées; à la place, les entrées non fusionnées sont ignorées.

Vous pouvez utiliser git stash – si quelque chose ne va pas, vous pouvez toujours revenir de la réserve. Semblable à une autre réponse ici, mais celle-ci supprime également tous les fichiers non-mappés ainsi que toutes les suppressions non mises en scène:

 git add . git stash 

Si vous vérifiez que tout va bien, jetez le cache:

 git stash drop 

La réponse de Bilal Maqsood avec git clean également fonctionné pour moi, mais avec la réserve j’ai plus de contrôle – si je le fais accidentellement, je peux toujours récupérer mes modifications

METTRE À JOUR

Je pense qu’il y a 1 changement de plus (je ne sais pas pourquoi cela a fonctionné pour moi avant):

git add . -A git add . -A au lieu de git add .

sans le -A les fichiers supprimés ne seront pas mis en scène

Au lieu de supprimer les modifications, je réinitialise ma télécommande à l’origine. Remarque – cette méthode consiste à restaurer complètement votre dossier à celui du repository.

Donc, je le fais pour m’assurer qu’ils ne restnt pas là quand je réinitialise git (plus tard – exclut gitignores sur l’origine / branchname)

REMARQUE: Si vous souhaitez conserver les fichiers qui ne sont pas encore suivis, mais pas dans GITIGNORE, vous pouvez ignorer cette étape, car cela effacera ces fichiers non détectés qui ne sont pas trouvés sur votre référentiel distant (merci @XtrmJosh).

 git add --all 

Alors je

 git fetch --all 

Puis je reviens à l’origine

 git reset --hard origin/branchname 

Cela va le remettre à la case départ. Tout comme RE-Cloner la twig, en gardant tous mes fichiers gitignored localement et en place.

Mise à jour par commentaire d’utilisateur ci-dessous: Variation pour réinitialiser le à la twig actuelle sur laquelle l’utilisateur est allumé.

 git reset --hard @{u} 

Essayé toutes les solutions ci-dessus, mais ne pouvait toujours pas se débarrasser de nouveaux fichiers non mis en scène.

Utilisez git clean -f pour supprimer ces nouveaux fichiers, mais avec prudence! Notez l’option de force.

Si vous souhaitez simplement supprimer les modifications apscopes aux fichiers existants , utilisez la checkout ( documentée ici ).

 git checkout -- . 
  • Aucune twig n’est spécifiée, elle vérifie donc la twig en cours.
  • Le trait d’union ( -- ) indique à Git que ce qui suit doit être considéré comme son deuxième argument (chemin), que vous avez ignoré la spécification d’une twig.
  • Le point ( . ) Indique tous les chemins.

Si vous souhaitez supprimer les fichiers ajoutés depuis votre dernier commit, utilisez clean ( documenté ici ):

 git clean -i 
  • L’option -i lance un clean interactif pour éviter les suppressions erronées.
  • Une poignée d’autres options sont disponibles pour une exécution plus rapide. voir la documentation.

Si vous souhaitez déplacer des modifications vers un espace de stockage pour un access ultérieur , utilisez stash ( documenté ici ):

 git stash 
  • Tous les changements seront transférés dans Git’s Stash, pour un access ultérieur possible.
  • Une poignée d’options sont disponibles pour un stockage plus nuancé. voir la documentation.

Utilisez simplement:

 git stash -u 

Terminé. Facile.

Si vous vous souciez vraiment de votre stack de réserve, vous pouvez la suivre avec une git stash drop . Mais à ce stade, il vaut mieux utiliser (de Mariusz Nowak):

 git checkout -- . git clean -df 

Néanmoins, j’aime git stash -u le meilleur car il “rejette” tous les changements suivis et non suivis en une seule commande . Pourtant, git checkout -- . ne rejette que les modifications suivies, et git clean -df ne rejette que les modifications non suivies … et taper les deux commandes est trop compliqué 🙂

dis simplement

 git stash 

Cela supprimera tous vos changements locaux. Vous pouvez également utiliser plus tard en disant

 git stash apply 

ou git stash pop

Cela fonctionne même dans les répertoires qui sont; en dehors des permissions git normales.

 sudo chmod -R 664 ./* && git checkout -- . && git clean -dfx 

Est arrivé à moi récemment

 cd path_to_project_folder # take you to your project folder/working directory git checkout . # removes all unstaged changes in working directory 

Une autre façon de se débarrasser de nouveaux fichiers plus spécifiques que git clean -df (cela vous permettra de vous débarrasser de certains fichiers pas forcément tous), est d’append les nouveaux fichiers à l’index, puis de les cacher, puis de les déposer. planque.

Cette technique est utile lorsque, pour une raison quelconque, vous ne pouvez pas supprimer facilement tous les fichiers non suivis par un mécanisme ordinaire (comme rm).

À mon avis,

 git clean -df 

devrait faire le tour. Selon la documentation de Git sur git clean

git-clean – Supprime les fichiers non suivis de l’arborescence de travail

La description

Nettoie l’arborescence en supprimant de manière récursive les fichiers qui ne sont pas sous contrôle de version, à partir du répertoire en cours.

Normalement, seuls les fichiers inconnus de Git sont supprimés, mais si l’option -x est spécifiée, les fichiers ignorés sont également supprimés. Cela peut, par exemple, être utile pour supprimer tous les produits de construction.

Si des arguments optionnels sont donnés, seuls ces chemins sont affectés.

Les options

-d Supprime les répertoires non suivis en plus des fichiers non suivis. Si un répertoire non suivi est géré par un référentiel Git différent, il n’est pas supprimé par défaut. Utilisez l’option -f deux fois si vous voulez vraiment supprimer un tel répertoire.

-f –force Si la variable de configuration Git clean.requireForce n’est pas définie sur false, git clean refuse de s’exécuter sauf si -f, -n ou -i.

Quel que soit l’état dans lequel se trouve votre repository, vous pouvez toujours réinitialiser à tout engagement précédent:

 git reset --hard  

Cela supprimera toutes les modifications apscopes après cette validation.

Ce qui suit n’est en réalité qu’une solution si vous travaillez avec un fork d’un référentiel où vous synchronisez régulièrement (par exemple, une requête pull) avec un autre référentiel. Réponse courte: effacez fork et refork, mais lisez les avertissements sur github .

J’ai eu un problème similaire, peut-être pas identique, et je suis sortingste de dire que ma solution n’est pas idéale, mais elle est finalement efficace.

J’avais souvent des messages de statut git comme celui-ci (impliquant au moins 2/4 fichiers):

 $ git status # Not currently on any branch. # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # modified: doc/PROJECT/MEDIUM/ATS-constraint/constraint_s2var.dats # modified: doc/PROJECT/MEDIUM/ATS-constraint/parsing/parsing_s2var.dats # # Changes not staged for commit: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: doc/PROJECT/MEDIUM/ATS-constraint/constraint_s2Var.dats # modified: doc/PROJECT/MEDIUM/ATS-constraint/parsing/parsing_s2Var.dats 

Un oeil vif notera que ces fichiers ont des dopplegangers qui sont une seule lettre au cas où. D’une manière ou d’une autre, et je n’ai aucune idée de ce qui m’a amené à démarrer dans cette voie (car je ne travaillais pas avec ces fichiers depuis le repository en amont), j’avais changé ces fichiers. Essayez les nombreuses solutions listées sur cette page (et les autres pages) ne semble pas avoir aidé.

J’ai pu résoudre le problème en supprimant mon référentiel fourchu et tous les référentiels locaux, et en réécrivant. Cela seul ne suffisait pas; upstream a dû renommer les fichiers en question en nouveaux noms de fichiers. Tant que vous ne travaillez pas, que vous n’avez pas de wiki et qu’aucun problème ne s’écarte du référentiel en amont, vous devez vous contenter. En amont, vous n’êtes peut-être pas très heureux avec vous, c’est le moins que l’on puisse dire. Pour ce qui est de mon problème, il s’agit sans aucun doute d’une erreur de l’utilisateur car je ne maîsortingse pas git, mais le fait qu’il soit loin d’être facile de corriger des points à un problème avec git également.

Lorsque vous souhaitez transférer une réserve à quelqu’un d’autre:

 # add files git add . # diff all the changes to a file git diff --staged > ~/mijn-fix.diff # remove local changes git reset && git checkout . # (later you can re-apply the diff:) git apply ~/mijn-fix.diff 

[edit] comme commenté, il est possible de nommer des stashes. Eh bien, utilisez ceci si vous voulez partager votre cachette;)

Si tous les fichiers mis en scène ont été réellement validés, la twig peut simplement être réinitialisée, par exemple depuis votre interface graphique avec environ trois clics de souris: Branche , Réinitialiser , Oui !

Donc, ce que je fais souvent en pratique pour annuler les modifications locales indésirables, c’est de valider toutes les bonnes choses, puis de réinitialiser la twig.

Si les bons éléments sont validés en une seule fois, vous pouvez utiliser “modifier la dernière validation” pour rétablir la mise en scène ou la mise en scène si vous souhaitez le commettre un peu différemment.

Ce n’est peut-être pas la solution technique que vous recherchez pour votre problème, mais je trouve cette solution très pratique. Il vous permet de supprimer sélectivement les modifications non planifiées, en réinitialisant les modifications que vous n’aimez pas et en conservant celles que vous faites.

Donc, en résumé, je commets simplement, réinitialise la twig et modifie le dernier commit .

Aucune des solutions ne fonctionne si vous venez de modifier les permissions d’un fichier (sous DOS / Windoze)

 Lun. 23/11 / 2015-15: 16: 34.80 C: \ ... \ work \ checkout \ slf4j +> git status
 Sur la twig SLF4J_1.5.3
 Modifications non prévues pour commit:
   (utilisez "git add ..." pour mettre à jour ce qui sera commis)
   (utilisez "git checkout - ..." pour ignorer les modifications dans le répertoire de travail)

         modifié: .gitignore
         modifié: LICENCE.txt
         modifié: TODO.txt
         modifié: codeStyle.xml
         modifié: pom.xml
         modifié: version.pl

 aucun changement ajouté à la validation (utilisez "git add" et / ou "git commit -a")

 Lun. 23/11 / 2015-15: 16: 37.87 C: \ ... \ work \ checkout \ slf4j +> git diff
 diff --git un / .gitignore b / .gitignore
 ancien mode 100644
 nouveau mode 100755
 diff --git un / LICENSE.txt b / LICENSE.txt
 ancien mode 100644
 nouveau mode 100755
 diff --git a / TODO.txt b / TODO.txt
 ancien mode 100644
 nouveau mode 100755
 diff --git a / codeStyle.xml b / codeStyle.xml
 ancien mode 100644
 nouveau mode 100755
 diff --git a / pom.xml b / pom.xml
 ancien mode 100644
 nouveau mode 100755
 diff --git a / version.pl b / version.pl
 ancien mode 100644
 nouveau mode 100755

 Lun. 23/11 / 2015-15: 16: 45.22 C: \ ... \ work \ checkout \ slf4j +> git reset --hard HEAD
 HEAD est maintenant à 8fa8488 12133-CHIXMISSINGMESSAGES MALCOLMBOEKHOFF 20141223124940 Ajouté .gitignore

 Lun 23/11 / 2015-15: 16: 47.42 C: \ ... \ work \ checkout \ slf4j +> git clean -f

 Lun. 23/11 / 2015-15: 16: 53.49 C: \ ... \ work \ checkout \ slf4j +> git stash save -u
 Enregistrement du répertoire de travail et de l'état d'index WIP sur SLF4J_1.5.3: 8fa8488 12133-CHIXMISSINGMESSAGES MALCOLMBOEKHOFF 20141223124940 Ajouté .gitignore
 HEAD est maintenant à 8fa8488 12133-CHIXMISSINGMESSAGES MALCOLMBOEKHOFF 20141223124940 Ajouté .gitignore

 Lun 23/11 / 2015-15: 17: 00.40 C: \ ... \ work \ checkout \ slf4j +>
 Refs / stash supprimés @ {0} (cb4966e9b1e9c9d8daa79ab94edc0c1442a294dd)

 Lun. 23/11 / 2015-15: 17: 06.75 C: \ ... \ work \ checkout \ slf4j +>
 Refs / stash supprimés @ {0} (e6c49c470f433ce344e305c5b778e810625d0529)

 Lun 23/11 / 2015-15: 17: 08.90 C: \ ... \ work \ checkout \ slf4j +>
 Aucune cachette trouvée.

 Lun 23/11 / 2015-15: 17: 15.21 C: \ ... \ work \ checkout \ slf4j +> git checkout -.

 Lun 23/11 / 2015-15: 22: 00.68 C: \ ... \ work \ checkout \ slf4j +> git checkout -f -.

 Lun 23/11 / 2015-15: 22: 04.53 C: \ ... \ work \ checkout \ slf4j +> git status
 Sur la twig SLF4J_1.5.3
 Modifications non prévues pour commit:
   (utilisez "git add ..." pour mettre à jour ce qui sera commis)
   (utilisez "git checkout - ..." pour ignorer les modifications dans le répertoire de travail)

         modifié: .gitignore
         modifié: LICENCE.txt
         modifié: TODO.txt
         modifié: codeStyle.xml
         modifié: pom.xml
         modifié: version.pl

 aucun changement ajouté à la validation (utilisez "git add" et / ou "git commit -a")

 Lun 23/11 / 2015-15: 22: 13.06 C: \ ... \ work \ checkout \ slf4j +> git diff
 diff --git un / .gitignore b / .gitignore
 ancien mode 100644
 nouveau mode 100755
 diff --git un / LICENSE.txt b / LICENSE.txt
 ancien mode 100644
 nouveau mode 100755
 diff --git a / TODO.txt b / TODO.txt
 ancien mode 100644
 nouveau mode 100755
 diff --git a / codeStyle.xml b / codeStyle.xml
 ancien mode 100644
 nouveau mode 100755
 diff --git a / pom.xml b / pom.xml
 ancien mode 100644
 nouveau mode 100755
 diff --git a / version.pl b / version.pl
 ancien mode 100644
 nouveau mode 100755

La seule façon de résoudre ce problème consiste à réinitialiser manuellement les permissions sur les fichiers modifiés:

 Lun. 23/11 / 2015-15: 25: 43.79 C: \ ... \ work \ checkout \ slf4j +> git status -s |  egrep "^ M" |  couper -c4- |  pour / f "jetons usebackq = * delims ="% A dans (`more`) chmod 644% ~ A

 Lun 23/11 / 2015-15: 25: 55.37 C: \ ... \ work \ checkout \ slf4j +> git status
 Sur la twig SLF4J_1.5.3
 rien à commettre, répertoire de travail propre

 Lun. 23/11 / 2015-15: 25: 59.28 C: \ ... \ work \ checkout \ slf4j +>

 Lun 23/11 / 2015-15: 26: 31.12 C: \ ... \ work \ checkout \ slf4j +> git diff

Vous pouvez créer votre propre alias qui décrit comment le faire de manière descriptive.

J’utilise l’alias suivant pour ignorer les modifications.


Ignorer les modifications dans un (fichier de) fichier (s) dans l’arborescence de travail

 discard = checkout -- 

Ensuite, vous pouvez l’utiliser comme prochaine pour ignorer toutes les modifications:

 discard . 

Ou juste un fichier:

 discard filename 

Sinon, si vous souhaitez supprimer toutes les modifications et les fichiers non suivis, j’utilise un mélange de vérification et de nettoyage:

Nettoyer et éliminer les modifications et les fichiers non suivis dans l’arborescence de travail

 cleanout = !git clean -df && git checkout -- . 

Donc, l’utilisation est simple comme suit:

 cleanout 

Maintenant est disponible dans le prochain repository Github qui contient beaucoup d’alias:

Si vous êtes en cas de sous-module et qu’aucune autre solution ne fonctionne, essayez:

  • Pour vérifier quel est le problème (peut-être un cas “sale”), utilisez:

    git diff

  • Pour supprimer la cachette

    git submodule update

J’ai eu une situation étrange où un fichier est toujours non mis en scène, cela m’aide à résoudre.

git rm .gitatsortingbutes
git add -A
git réinitialiser –hard