1
votes

git reset --hard ne fonctionne pas après le réglage de la tête

Lorsque je fais git reset --hard pour annuler les modifications de la copie de travail actuelle, rien n'est supprimé.

Voici ce que j'ai fait avant ce problème: J'ai reculé la tête de 3 commits git reset HEAD ~ 3 Ensuite, j'ai voulu revenir au dernier commit, et j'ai pensé que ça le ferait git checkout - Ce que cela fait, c'est vérifier la branche de développement avec des changements que je ne veux pas. Maintenant, je veux revenir à ma branche précédente sans valider ces changements mais je ne peux pas changer de branche à cause de ces changements. git reset --hard ne fait rien. A a également essayé de cacher les modifications, elles sont bloquées, mais la copie de travail ne supprimera pas les modifications de ma copie de travail.

Modifier: Voici la sortie de l'état de git:

On branch development
Your branch is up to date with 'origin/development'.

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)

    deleted:    Muqeem/Modules/Muqeem/Slide Down /SlideDownViewController.swift
    deleted:    Muqeem/Modules/Muqeem/Slide Down /SlideDownViewController.xib
    deleted:    Muqeem/Modules/Muqeem/Tabs/Swiping Controller /PageCollectionViewCell.swift
    deleted:    Muqeem/Modules/Muqeem/Tabs/Swiping Controller /SwipingViewController.swift
    deleted:    Muqeem/Modules/Muqeem/Tabs/Swiping Controller /SwipingViewController.xib

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    Muqeem/Modules/Muqeem/Slide Down (Whitespace Conflict)/
    Muqeem/Modules/Muqeem/Slide Down/
    Muqeem/Modules/Muqeem/Tabs/Swiping Controller (Whitespace Conflict)/
    Muqeem/Modules/Muqeem/Tabs/Swiping Controller/

no changes added to commit (use "git add" and/or "git commit -a")


5 commentaires

Pourriez-vous coller le résultat de git status ?


"Je ne peux pas faire git reset --hard " est différent de " git reset --hard ne fait rien", le premier signifie qu'il y a une raison pour laquelle vous ne pouvez pas utilisez cette commande, la seconde est que vous avez essayé d'utiliser cette commande et qu'elle n'a pas fait ce que vous attendiez. Pouvez-vous expliquer de quoi il s'agit? De plus, git reset --hard doit généralement savoir ce que vous voulez qu'il réinitialise à . As-tu fais ça?


@ LasseVågsætherKarlsen Oui git reset --hard ne fait rien. Je veux réinitialiser toutes les modifications donc pas besoin de spécifier un fichier particulier.


Le fait que vous ayez mis ceci sous Dropbox est absent de la question!


@torek Vous avez raison. Je ne m'y attendais pas du tout.


3 Réponses :


0
votes

D'après votre description, je comprends que vous souhaitez que toutes les modifications disparaissent. git status révèle que vous avez des fichiers supprimés et également des fichiers non suivis. Vous pouvez restaurer ceux-ci:

    deleted:    Muqeem/Modules/Muqeem/Slide Down /SlideDownViewController.swift
    deleted:    Muqeem/Modules/Muqeem/Slide Down /SlideDownViewController.xib
    deleted:    Muqeem/Modules/Muqeem/Tabs/Swiping Controller /PageCollectionViewCell.swift
    deleted:    Muqeem/Modules/Muqeem/Tabs/Swiping Controller /SwipingViewController.swift
    deleted:    Muqeem/Modules/Muqeem/Tabs/Swiping Controller /SwipingViewController.xib

en exécutant par exemple git checkout -.

Ceux qui ne sont pas suivis ne sont pas gérés par git, car ils n'y ont pas été ajoutés. Vous pouvez les supprimer à la main si c'est ce que vous voulez rm -r Muqeem / Modules / Muqeem / Slide \ Down \ (Whitespace \ Conflict) (et ainsi de suite) et ils disparaîtront de état git .


2 commentaires

J'ai réussi à supprimer les fichiers. Mais ne peut toujours pas annuler la suppression des fichiers supprimés. La commande git checkout -. lorsqu'elle est exécutée, ramène les fichiers non suivis. C'est comme si les fichiers supprimés ne sont pas suivis !.


Maintenant, j'ai réalisé qu'il y avait des espaces à la fin des noms de dossier ... Je n'ai jamais rencontré un tel problème (je suis la règle pour éviter les espaces dans les chemins) donc la solution ci-dessous est juste mon hypothèse: rm -r Muqeem / Modules / Muqeem / Slide \ Down \ \ (Whitespace \ Conflict \) / rm -r Muqeem / Modules / Muqeem / Tabs / Swiping \ Controller \ \ (Whitespace \ Conflict \) / git add Muqeem / Modules / Muqeem / Slide \ Down / git add Muqeem / Modules / Muqeem / Tabs / Swiping \ Controller / git commit -a -m "Problèmes résolus avec les espaces aux extrémités des dossiers" Essayez ceci si vous êtes d'accord pour créer un nouveau commit (copiez le dépôt premier).



0
votes

Si je comprends bien, vous souhaitez vous débarrasser des modifications actuellement présentes dans votre sortie git status , et vous souhaitez basculer vers votre branche.

Git se plaindra du changement de branche lorsque vous avez des changements non stagés de fichiers suivis présents dans votre répertoire de travail. Git ne se plaindra pas de changer de branche lorsque des fichiers non suivis sont présents dans votre répertoire de travail.

Alors décomposons-le.

Pour se débarrasser des changements (non) par étapes, exécutez git reset --hard . Cela annule les modifications apportées aux fichiers suivis.

Maintenant, nous verrons toujours les fichiers non suivis présents lorsque nous exécuterons git status . Mais à ce stade, nous devrions pouvoir changer de branche. Lorsque vous passez à votre branche et exécutez git status , il ne devrait rien y avoir, sauf pour ces fichiers non suivis.

Enfin, si vous voulez vous en débarrasser, vous pouvez soit les supprimer manuellement, soit utiliser une commande conçue pour cela: exécutez git clean -nd - cela fera un "dry run" , listant tous les fichiers qui seraient supprimés (je préfère toujours faire une analyse à sec pour ne rien faire de regrettable, -d supprimera les répertoires non suivis en plus des fichiers non suivis). Si vous êtes satisfait du résultat, lancez-le pour de vrai: git clean -df ( -f est pour force, il est requis dans la plupart des cas par défaut). < / p>


0 commentaires

0
votes

De manière inattendue, le coupable est Dropbox. Après avoir déplacé mon projet de Dropbox, git reset --hard a fonctionné comme prévu.


1 commentaires

Cela aurait dû être prévu. Dropbox tente de contrôler les fichiers (car ils sont partagés sur plusieurs machines). Git tente de contrôler les fichiers (car c'est un système de contrôle de version , après tout). Qui espérez-vous gagner ce combat pour le contrôle, et pourquoi? Est-il sage que vos fichiers mènent des batailles en cage MMA comme celle-ci? :-)