l'état de git montre des modifications, git checkout - <fichier> ne les supprime pas


222

Je souhaite supprimer toutes les modifications apportées à ma copie de travail.
L'exécution git statusmontre les fichiers modifiés.
Rien de ce que je fais ne semble supprimer ces modifications.
Par exemple:

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git reset --hard HEAD
HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated.

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

6
Je ne sais pas pourquoi cela git reset --hardn'a pas fonctionné ici. Remarque: cela devrait être git checkout -- `git ls-files -m`d'annuler les fichiers ( --)
VonC

2
Si vous supprimez les fichiers et les utilisez, checkout -- <file>cela devrait fonctionner. La détection de changement est un peu difficile dans certaines situations (entre autres si une incompatibilité CRLF est présente)
vérifie


1
@ BuZZ-dEE - il s'agit d'un doublon, et plus ancien et aurait donc la priorité. Mais alors que la question à laquelle vous créez un lien est essentiellement la même, la réponse que j'ai acceptée ci-dessous est beaucoup plus informative que n'importe laquelle des réponses qui y sont, et a résolu mon problème.
rbellamy

pas une solution, mais un couteau suisse pour le cas ennuyeux: git update-index --assume-unchagedforce l'état non ficelé des fichiers (même pour les fichiers modifiés!)
pdem

Réponses:


126

Il existe plusieurs problèmes qui peuvent provoquer ce problème:

Normalisation de fin de ligne

J'ai aussi eu ce genre de problèmes. Cela revient à git convertir automatiquement crlf en lf. Cela est généralement dû à des fins de ligne mixtes dans un seul fichier. Le fichier est normalisé dans l'index, mais lorsque git le dénormalise à nouveau pour le différencier du fichier dans l'arborescence de travail, le résultat est différent.

Mais si vous souhaitez résoudre ce problème, vous devez désactiver core.autocrlf , remplacer toutes les fins de ligne par lf, puis le réactiver . Ou vous pouvez le désactiver complètement en faisant:

git config --global core.autocrlf false

Au lieu de core.autocrlf , vous pouvez également envisager d'utiliser des .gitattributefichiers. De cette façon, vous pouvez vous assurer que toutes les personnes utilisant le référentiel utilisent les mêmes règles de normalisation, empêchant les fins de ligne mixtes d'entrer dans le référentiel.

Pensez également à définir core.safecrlf pour avertir si vous voulez que git vous avertisse lorsqu'une normalisation non réversible sera effectuée.

Les pages de manuel git disent ceci:

La conversion CRLF a une légère chance de corrompre les données. autocrlf = true convertira CRLF en LF lors de la validation et LF en CRLF lors du paiement. Un fichier qui contient un mélange de LF et CRLF avant la validation ne peut pas être recréé par git. Pour les fichiers texte, c'est la bonne chose à faire: cela corrige les fins de ligne de telle sorte que nous n'avons que des fins de ligne LF dans le référentiel. Mais pour les fichiers binaires qui sont accidentellement classés comme du texte, la conversion peut corrompre les données.

Systèmes de fichiers insensibles à la casse

Sur les systèmes de fichiers insensibles à la casse, lorsque le même nom de fichier avec une casse différente se trouve dans le référentiel, git essaie de retirer les deux, mais un seul se retrouve sur le système de fichiers. Lorsque git essaie de comparer le second, il le compare au mauvais fichier.

La solution serait soit de passer à un système de fichiers non sensible à la casse, mais dans la plupart des cas, cela n'est pas possible ou de renommer et de valider l'un des fichiers sur un autre système de fichiers.


8
D'accord ... donc ça l'a fait ... maintenant l'état git ne montre aucun changement. J'ai lu les paramètres autocrlf, et je n'arrive pas à faire les choses correctement.
rbellamy

1
Bonne prise! +1. Encore un autre argument pour moi de définir cela sur faux ( stackoverflow.com/questions/1249932/… ).
VonC

Qu'est-ce que cela signifie: "Un fichier qui contient un mélange de LF et CRLF avant la validation ne peut pas être recréé par git." Est-ce parce que git normalisera toujours les fins de ligne, en fonction du paramètre core.autocrlf?
rbellamy le

1
Une solution plus sensée au problème de respect de la casse est de ne pas avoir plusieurs dossiers dans votre référentiel dont les noms ne diffèrent que par la casse .
Ohad Schneider

3
Pour rechercher des noms de fichiers qui ne diffèrent que par la casse des lettres, vous pouvez exécuter git ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d. Pour répertorier les noms en majuscules et en minuscules de ces fichiers, exécutezgit ls-tree -r --name-only HEAD | fgrep -i -f <(git ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d) | sort -i
Diomidis Spinellis

220

J'avais ce problème sur Windows, mais je n'étais pas prêt à étudier les ramifications de l'utilisation. config --global core.autocrlf falseJe n'étais pas non plus prêt à abandonner d'autres branches privées et goodies dans ma cachette et à commencer avec un nouveau clone. J'ai juste besoin de faire quelque chose. Maintenant.

Cela a fonctionné pour moi, sur l'idée que vous laissiez git réécrire complètement votre répertoire de travail:

git rm --cached -r .
git reset --hard

(Notez que l'exécution git reset --hardn'était tout simplement pas assez bonne ni une plaine rmsur les fichiers avant le resetcomme suggéré dans les commentaires de la question d'origine)


8
Un autre succès ici après avoir changé core.autocrlfn'a eu aucun effet.
Daniel Buckmaster

8
Avait ce problème sur Windows même avec core.autocrlf false. Cette réponse a fonctionné quand rien d'autre ne le ferait.
kenchilada

9
J'ai essayé plusieurs suggestions de cette question et d'autres. C'est le seul correctif qui a fonctionné pour moi. Je n'avais aucun fichier d'attribut et j'ai déjà commencé avec core.autocrlf à false.
BrotherOdin

4
Cela n'a pas fonctionné pour moi. Donc, je l'ai fait de façon plus laide en créant une nouvelle branche juste pour valider ces changements car ils sont de toute façon inutiles pour moi. [java] git checkout -b a-branch-to-commit-bad-crlf-files [/ java] [java] git commit -am "validation des mauvais fichiers crlf" [/ java]
Mohd Farid

3
Parfois, des problèmes comme celui-ci me font vraiment manquer SVN.
Mike Godin

104

Une autre solution qui peut fonctionner pour les gens, car aucune des options de texte n'a fonctionné pour moi:

  1. Remplacez le contenu .gitattributesavec une seule ligne: * binary. Cela indique à git de traiter chaque fichier comme un fichier binaire avec lequel il ne peut rien faire.
  2. Vérifiez que le message pour les fichiers incriminés a disparu; si ce n'est pas le cas, vous pouvez git checkout -- <files>les restaurer dans la version du référentiel
  3. git checkout -- .gitattributesrestaurer le .gitattributesfichier à son état initial
  4. Vérifiez que les fichiers ne sont toujours pas marqués comme modifiés.

1
J'ai été bloqué sur le fait de ne pas pouvoir restaurer, extraire ou cacher des fichiers au cours des dernières heures. C'était la solution pour moi! Merci! (Git 1.8.3.1)
NuSkooler

3
J'ai essayé beaucoup de choses avant de finalement réussir avec ça. Je vous remercie!
ghenghy

1
Comment cela marche-t-il? Je pense que revenir .gitattributesà l'original réintroduirait le même problème, mais hélas mon problème est maintenant résolu. Aucune des autres suggestions n'a fonctionné dans mon cas.
jdk1.0

1
@ jdk1.0 ma compréhension / supposition est que deux méthodes de comparaison différentes sont impliquées. L'erreur se produit lorsque vous avez une ligne différente se terminant quelque part, et git l'ignore parfois. Lorsque vous demandez git status, il constate que ce sont des fichiers différents. Lorsque vous demandez git checkout, il constate qu'ils ont le même contenu. Cette solution demande temporairement à git d'ignorer toute intelligence de fin de ligne possible et de s'assurer que votre copie locale est identique octet par octet à celle de HEAD. Une fois que cela a été résolu, permettre à l'intelligence de reprendre est correct, car cela n'ajoutera pas de nouvelles erreurs.
zebediah49

3
J'ai passé quelques heures à résoudre ce problème et cette solution a finalement fonctionné pour moi!
Maryam

71

Pour les futures personnes ayant ce problème: Les modifications du mode de fichier peuvent également présenter les mêmes symptômes. git config core.filemode falseva le réparer.


3
Après cela, vous devrez peut-être fairegit checkout .
Marty Neal

2
A travaillé pour moi sans avoir à nouveau
payer

3
Pour référence future: pour savoir si c'est le correctif dont vous avez besoin (et non les autres correctifs dans d'autres réponses), utilisez git diffet il affichera les fichiers avec des changements de mode comme celui-ci old mode 100755 / new mode 100644.
pgr

Cela m'a corrigé après absolument rien d'autre. Je ne pense vraiment pas que les gens devraient faire des cheatsheets et des "guides simples" sur Internet. Git n'est vraiment pas quelque chose à ramasser et à utiliser, je pense que c'est quelque chose que vous devez avoir une formation dédiée et formelle avant de l'utiliser.

Merci, tu m'as sauvé beaucoup de larmes!
Lukasz

33

Cela m'a rendu fou, surtout que je ne pouvais pas résoudre ce problème sans aucune des solutions trouvées en ligne. Voici comment je l'ai résolu. Je ne peux pas prendre les crédits ici car c'est le travail d'un collègue :)

Source du problème: Mon installation initiale de git s'est faite sans conversion de ligne automatique sur Windows. Cela a provoqué mon commit initial à GLFW sans la fin de ligne appropriée.

Remarque: ce n'est qu'une solution locale. Le prochain gars clonant le dépôt sera toujours coincé avec ce problème. Une solution permanente peut être trouvée ici: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository .

Installation: Xubuntu 12.04 Git repo avec projet glfw

Problème: impossible de réinitialiser les fichiers glfw. Ils apparaissent toujours comme modifiés, indépendamment de ce que j'ai essayé.

Résolu:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Il pourrait être utile de mentionner le contenu de la ligne commentée.
rbellamy

Malheureusement, la plupart des projets n'ont pas ce fichier .gitattribute facultatif
mchiasson

Je vous remercie. Je ne comprends tout simplement pas pourquoi cela est nécessaire
diogovk

Pourquoi? Fondamentalement, il s'agit d'un correctif temporaire à la fin de la ligne. Utilisez la solution permanente en suivant le lien dans la note.
Richard Lalancette

11

J'avais un fichier .bat avec le même problème (impossible de le supprimer dans les fichiers non suivis). git checkout - n'a pas fonctionné, ni aucune des suggestions sur cette page. La seule chose qui a fonctionné pour moi a été de faire:

git stash save --keep-index

Et puis pour supprimer la cachette:

git stash drop

Cela a fonctionné pour moi. Notez que --keep-indexc'est important.
user991710

Pourquoi le --keep-index est-il important?
Choylton B. Higginbottom

8

Vous avez le même problème deux fois! Les deux fois où j'ai caché des changements, j'ai fait et j'ai essayé de les faire revenir. Impossible de faire apparaître les modifications car j'ai beaucoup de fichiers qui ont été modifiés - mais ils ne le sont PAS! Ils sont exactement les mêmes.

Je pense maintenant que j'ai essayé toutes les solutions ci-dessus sans succès. Après avoir essayé le

git rm --cached -r .
git reset --hard

J'ai maintenant modifié presque tous les fichiers de mon référentiel.

Lorsque vous différez le fichier, il indique que j'ai supprimé toutes les lignes, puis les ai ajoutées à nouveau.

Un peu dérangeant. Je vais maintenant éviter de planquer à l'avenir ..

La seule solution est de cloner un nouveau référentiel et de recommencer. (Fait la dernière fois)


6

Essayez de faire un

git checkout -f

Cela devrait effacer tous les changements dans le référentiel local de travail actuel


Agréable! Cela a fonctionné pour moi. Bien que pour un cas têtu, je devais d'abord git checkout -f <another recent branch>retourner dans ma succursale avecgit checkout -f <branch I'm working on>
Ingénieur inversé

4

Je n'ai pu résoudre ce problème qu'en supprimant temporairement le fichier .gitattributes de mon référentiel (qui définissait * text=autoet *.c text).

J'ai couru git statusaprès la suppression et les modifications avaient disparu. Ils ne sont pas revenus même après la remise en place de .gitattributes.


Cela fonctionne même avec des attributs plus compliqués, par exemple des filtres
Samizdis

2

Avoir des fins de ligne cohérentes est une bonne chose. Par exemple, il ne déclenchera pas de fusions inutiles, bien que triviales. J'ai vu Visual Studio créer des fichiers avec des fins de ligne mixtes.

Certains programmes comme bash (sous linux) nécessitent également que les fichiers .sh soient terminés en LF.

Pour vous assurer que cela se produit, vous pouvez utiliser gitattributes. Il fonctionne au niveau du référentiel quelle que soit la valeur de autcrlf.

Par exemple, vous pouvez avoir .gitattributes comme ceci: * text = auto

Vous pouvez également être plus spécifique par type / extension de fichier si cela importait dans votre cas.

Autocrlf peut alors convertir localement les fins de ligne pour les programmes Windows.

Sur un projet mixte C # / C ++ / Java / Ruby / R, Windows / Linux, cela fonctionne bien. Aucun problème jusqu'à présent.


2

J'ai également eu les mêmes symptômes mais a été causée par une chose différente.

Je n'étais pas capable de:

git checkout app.js //did nothing
git rm app.js //did nothing
rm -rf app.js //did nothing

même sur git rm --cached app.jscelui-ci signe comme supprimé et dans les fichiers non suivis, je pouvais voir app.js. Mais quand j'ai essayé rm -rf app.jset peform git statusencore , il me montre encore le fichier dans « untracked ».

Après quelques essais avec un collègue, nous avons découvert que cela avait été causé par Grunt!

Comme le Grunta été activé, et parce que app.js a été généré à partir de quelques autres fichiers js, nous avons découvert qu'après chaque opération avec des fichiers js (également ce app.js) grunt recrée à nouveau app.js.


2

Ce problème peut également se produire lorsqu'un contributeur au dépôt fonctionne sur une machine Linux ou lorsque les fenêtres avec Cygwin et les autorisations de fichier sont modifiées. Git ne connaît que 755 et 644.

Exemple de ce problème et comment le vérifier:

git diff styleguide/filename

diff --git a/filename b/filename
old mode 100644
new mode 100755

Pour éviter cela, vous devez vous assurer de configurer correctement git en utilisant

git config --global core.filemode false

2

Il y a beaucoup de solutions ici et j'aurais peut-être dû essayer certaines d'entre elles avant d'en arriver à la mienne. Quoi qu'il en soit, voici un de plus ...

Notre problème était que nous n'avions aucune application pour les endlines et le référentiel avait un mélange de DOS / Unix. Le pire, c'est qu'il s'agissait en fait d'un référentiel open source dans cette position, et que nous avions bifurqué. La décision a été prise par ceux qui détiennent la propriété principale du référentiel du système d'exploitation de changer toutes les lignes de terminaison en Unix et la validation a été prise qui comprenait un .gitattributespour appliquer les fins de ligne.

Malheureusement, cela semblait causer des problèmes similaires à ceux décrits ici où une fois une fusion de code antérieure à DOS-2-Unix effectuée, les fichiers seraient marqués pour toujours comme modifiés et ne pourraient pas être annulés.

Au cours de mes recherches à ce sujet, je suis tombé sur - https://help.github.com/articles/dealing-with-line-endings/ - Si je fais à nouveau face à ce problème, je commencerais par essayer ceci.


Voici ce que j'ai fait:

  1. J'avais initialement fait une fusion avant de réaliser que j'avais ce problème et que je devais l'annuler - git reset --hard HEAD( j'ai rencontré un conflit de fusion. Comment puis-je abandonner la fusion? )

  2. J'ai ouvert les fichiers en question dans VIM et suis passé à Unix ( :set ff=unix). Un outil comme dos2unixpourrait être utilisé au lieu de cours

  3. engagé

  4. fusionné masterdans (le maître a les modifications DOS-2-Unix)

    git checkout old-code-branch; git merge master

  5. Les conflits ont été résolus et les fichiers étaient à nouveau DOS, donc :set ff=unixje devais quand dans VIM. (Notez que j'ai installé https://github.com/itchyny/lightline.vim qui m'a permis de voir quel est le format de fichier sur la ligne d'état VIM)

  6. engagé. Tout trié!

2

Le problème que j'ai rencontré est que Windows ne se soucie pas de la capitalisation du nom de fichier, mais git le fait. Git a donc stocké une version inférieure et majuscule du fichier mais n'a pu en extraire qu'une.


2

J'ai validé toutes les modifications, puis j'ai effectué et annulé la validation. Cela a fonctionné pour moi

git add.

git commit -m "Validation aléatoire"

git reset --hard HEAD ~ 1


2

Normalement, dans GIT pour effacer toutes vos modifications et nouveaux fichiers, les 2 commandes suivantes devraient fonctionner très bien ( faites attention , cela supprimera tous vos nouveaux fichiers + dossiers que vous avez peut-être créés et restaurera tous vos fichiers modifiés à l'état de votre courant) valider ):

$ git clean --force -d
$ git checkout -- .

Peut-être qu'une meilleure option est parfois de simplement faire "git stash push" avec un message facultatif, comme ceci:

$ git stash push -m "not sure if i will need this later"

Cela effacera également tous vos fichiers nouveaux et modifiés, mais vous les aurez tous cachés au cas où vous souhaiteriez les restaurer. Stash dans GIT est transporté de branche en branche, vous pouvez donc les restaurer dans une autre branche, si vous le souhaitez.

En guise de remarque, si vous avez déjà mis en scène des fichiers récemment ajoutés et que vous souhaitez vous en débarrasser, cela devrait faire l'affaire:

$ git reset --hard

Si tout ce qui précède ne fonctionne pas pour vous , lisez ci-dessous ce qui a fonctionné pour moi il y a quelque temps:

J'ai rencontré ce problème plusieurs fois auparavant. Je développe actuellement sur une machine Windows 10 fournie par mon employeur. Aujourd'hui, ce comportement git particulier a été provoqué par la création d'une nouvelle branche à partir de ma branche "develop". Pour une raison quelconque, après être revenu à la branche "développer", certains fichiers apparemment aléatoires persistaient et apparaissaient comme "modifiés" dans "git status".

De plus, à ce moment-là, je ne pouvais pas commander une autre branche, donc j'étais coincé sur ma branche "développer".

C'est ce que j'ai fait:

$ git log

J'ai remarqué que la nouvelle branche que j'ai créée à partir de "develop" plus tôt dans la journée montrait dans le premier message "commit", étant référencée à la fin "HEAD -> develop, origin / develop, origin / HEAD, The-branch-i-created -plus tôt-aujourd'hui ".

Comme je n'en avais pas vraiment besoin, je l'ai supprimé:

$ git branch -d The-branch-i-created-earlier-today

Les fichiers modifiés apparaissaient toujours, alors j'ai fait:

$ git stash

Cela a résolu mon problème:

$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean

Bien sûr $ git stash list, les modifications seront cachées, et comme j'en avais peu et que je n'avais besoin d'aucune de mes cachettes, je l'ai fait $ git stash clearpour SUPPRIMER TOUTES LES CACHEES.

REMARQUE : je n'ai pas essayé de faire ce que quelqu'un a suggéré ici avant moi:

$ git rm --cached -r .
$ git reset --hard

Cela a peut-être aussi bien fonctionné, je serai sûr de l'essayer la prochaine fois que je rencontrerai ce problème.


1

Si vous clonez un référentiel et voyez instantanément les modifications en attente, le référentiel est dans un état incohérent. Veuillez NE PAS commenter * text=autole .gitattributesfichier. Cela a été mis spécifiquement parce que le propriétaire du référentiel veut que tous les fichiers soient stockés de manière cohérente avec les fins de ligne LF.

Comme indiqué par HankCa, suivre les instructions sur https://help.github.com/articles/dealing-with-line-endings/ est la voie à suivre pour résoudre le problème. Bouton facile:

git clone git@host:repo-name
git checkout -b normalize-line-endings
git add .
git commit -m "Normalize line endings"
git push
git push -u origin normalize-line-endings

Puis fusionnez (ou extrayez la demande) la branche au propriétaire du référentiel.


1

Rien d'autre sur cette page n'a fonctionné. Cela a finalement fonctionné pour moi. Ne montrant aucun fichier non suivi ou engagé.

git add -A
git reset --hard

1

Pour moi, le problème était que Visual Studio a été ouvert lors de l'exécution de la commande

git checkout <file>

Après avoir fermé Visual Studio, la commande a fonctionné et j'ai finalement pu appliquer mon travail à partir de la pile. Vérifiez donc toutes les applications susceptibles d'apporter des modifications à votre code, par exemple SourceTree, SmartGit, NotePad, NotePad ++ et d'autres éditeurs.


0

Nous étions confrontés à une situation similaire dans notre entreprise. Aucune des méthodes proposées ne nous a aidés. À la suite de la recherche, le problème a été révélé. Le fait était que dans Git, il y avait deux fichiers, dont les noms ne différaient que dans le registre des symboles. Les systèmes Unix les considéraient comme deux fichiers différents, mais Windows devenait fou. Pour résoudre le problème, nous avons supprimé l'un des fichiers sur le serveur. Après cela, dans les référentiels locaux sous Windows, les commandes suivantes ont été aidées (dans différentes séquences):

git reset --hard
git pull origin
git merge

0

Je l'ai résolu en éditant .git / config, en ajoutant:

[branch "name_branch"]
    remote = origin
    merge = refs/heads/name_branch

Ensuite, je suis allé dans .git / refs / heads / name_branch et j'ai placé l'id du dernier commitenter code here


0

Je l'ai résolu de cette façon:

  1. Copiez le contenu du code correct que vous souhaitez
  2. Supprimez le fichier à l'origine du problème (celui que vous ne pouvez pas rétablir) de votre disque. vous devriez maintenant trouver les deux versions du même fichier marquées comme étant supprimées.
  3. Validez la suppression des fichiers.
  4. Créez à nouveau le fichier avec le même nom et collez le code correct que vous avez copié à l'étape 1
  5. valider la création du nouveau fichier.

C'est ce qui a fonctionné pour moi.


0

Une solution proposée ici n'a pas fonctionné, j'ai découvert que le fichier était en fait un lien vers des caractères spéciaux:

% ls -l StoreLogo.png
lrwxrwxrwx 1 janus janus 8 Feb 21 10:37 StoreLogo.png -> ''$'\211''PNG'$'\r\n\032\n'

% git status    
Changes not staged for commit:
    modified:   StoreLogo.png

% git rm --cached -r StoreLogo.png
rm 'src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png'

% git reset StoreLogo.png         
Unstaged changes after reset:
M   src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png

% git status                      
Changes not staged for commit:
    modified:   StoreLogo.png
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.