Miałem ten sam problem i był związany z plikiem .gitattributes. Jednak Typ pliku, który spowodował problem, nie został określony w .gitattributes.

Udało mi się rozwiązać problem po prostu uruchamiając

git rm .gitattributes
git add -A
git reset --hard

Git nie resetuje plików, których nie ma w repozytorium. Więc możesz:

$ git add .
$ git reset --hard

Spowoduje to wprowadzenie wszystkich zmian, co spowoduje, że Git będzie wiedział o tych plikach, a następnie je zresetuje.

Jeśli to nie zadziała, możesz spróbować ukryć i upuścić swoje zmiany:

$ git stash
$ git stash drop

Rozwiązany!!!

Rozwiązałem ten problem używając następujących stpes

1) Usuń każdy plik z indeksu Gita.

git rm --cached -r .

2) Przepisz indeks Git, aby pobrać wszystkie nowe zakończenia linii.

git reset --hard

Rozwiązanie było częścią kroków opisanych na stronie git https://help.github.com/articles/dealing-with-line-endings/

Miałem ten sam problem i stash, hard reset, clean, a nawet wszystkie wciąż zostawiały zmiany. Problemem okazał się tryb pliku X, który nie został poprawnie ustawiony przez git. Jest to "znany problem" z Gitem Dla windows. Lokalne zmiany są wyświetlane w gitk i GIT status jako stary tryb 100755 nowy tryb 100644, bez żadnych rzeczywistych różnic w plikach.

Poprawką jest ignorowanie trybu pliku:

git config core.filemode false

Więcej informacji tutaj

Możliwa Przyczyna # 1-Normalizacja Zakończenia Linii

Jedna z sytuacji, w której może się to zdarzyć, to sytuacja, w której dany plik został sprawdzony w repozytorium bez poprawnej konfiguracji dla zakończeń linii (1), co skutkuje plikiem w repozytorium z nieprawidłowymi zakończeniami linii lub mieszanymi zakończeniami linii. Aby potwierdzić, sprawdź, czy git diff pokazuje tylko zmiany w zakończeniach linii (mogą one nie być domyślnie widoczne, spróbuj git diff | cat -v zobaczyć zwraca karetki jako literał ^M postaci).

Następnie ktoś prawdopodobnie dodał .gitattributes lub zmodyfikował ustawienie core.autocrlf, aby znormalizować zakończenia linii (2). W oparciu o konfigurację .gitattributes lub globalną, Git zastosował lokalne zmiany do twojej kopii roboczej, które stosują wymaganą normalizację końcową linii. Niestety, z jakiegoś powodu git reset --hard nie cofnie tych zmian normalizacji linii.

Rozwiązanie

Obejścia, w których zresetowane są lokalne zakończenia linii, nie rozwiążą problemu. Za każdym razem plik jest "widziany" przez git, spróbuje ponownie zastosować normalizację, powodując ten sam problem.

Najlepszą opcją jest to, aby git zastosował normalizację, którą chce, normując wszystkie zakończenia linii w repo, aby pasowały do .gitattributes, i zatwierdzając te zmiany -- zobacz próbując naprawić zakończenia linii za pomocą git filter-branch, ale bez powodzenia.

Jeśli naprawdę chcesz spróbować ręcznie przywrócić zmiany do pliku to najłatwiejszym rozwiązaniem wydaje się być usunięcie zmodyfikowanych pliki, a następnie powiedzieć git, aby je przywrócić, chociaż zauważam, że to rozwiązanie nie wydaje się działać konsekwentnie 100% czasu (ostrzeżenie: nie uruchom to, jeśli zmodyfikowane pliki mają zmiany inne niż zakończenia linii!!):

    git status --porcelain | grep "^ M" | cut -c4- | xargs rm
    git checkout -- .

Zauważ, że jeśli w pewnym momencie Nie znormalizujesz zakończeń linii w repozytorium, nadal będziesz napotykać ten problem.

Możliwa Przyczyna # 2 - Niewrażliwość Na Przypadki

Drugą możliwą przyczyną jest niewrażliwość na wielkość liter w systemie Windows na przykład, powiedzmy, że w repozytorium istnieje ścieżka podobna do następującej:

/foo/bar

Teraz ktoś na Linuksie zatwierdza pliki do /foo/Bar (prawdopodobnie przez narzędzie do budowania lub coś, co utworzyło ten katalog) i wypycha. W Linuksie są to obecnie dwa oddzielne katalogi:

/foo/bar/fileA
/foo/Bar/fileA

Sprawdzenie tego repo na Windows lub Mac może spowodować modyfikację fileA, której nie można zresetować, ponieważ przy każdym resecie git na Windows sprawdza się /foo/bar/fileA, a następnie ponieważ Windows jest niewrażliwe na wielkość liter, nadpisuje zawartość fileA przez /foo/Bar/fileA, co powoduje ich "modyfikację".

Innym przypadkiem może być pojedynczy (- E) plik (- Y), który (- E) istnieje (- ą) w repo, który (- E) po sprawdzeniu na niewrażliwym na wielkość liter systemie plików nakładałby się na siebie. Na przykład:

/foo/bar/fileA
/foo/bar/filea

Mogą być inne podobne sytuacje, które mogą powodować takie problemy.

Git na systemach plików niewrażliwych na wielkość liter powinien naprawdę wykryć tę sytuację i pokazać użyteczny komunikat ostrzegawczy, ale obecnie nie (może się to zmienić w przyszłości -- Zobacz ta dyskusja i powiązane proponowane poprawki na Gita.lista dyskusyjna git).

Rozwiązanie

Rozwiązaniem jest wyrównanie przypadków plików w indeksie git i przypadków w systemie plików Windows. Można to zrobić na Linuksie, który pokaże prawdziwy stan rzeczy, lub na Windows z bardzo użytecznym narzędziem open source Git-Unite. Git-Unite zastosuje niezbędne zmiany case do indeksu git, które następnie można zobowiązać do repo.

(1) było to najprawdopodobniej przez kogoś używającego systemu Windows, bez żadnej definicji .gitattributes dla danego pliku i używając domyślnego globalnego ustawienia dla core.autocrlf, czyli false (zobacz (2)).

(2) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/

Inną przyczyną tego może być niewrażliwe na wielkość liter systemy plików . Jeśli masz wiele folderów w repo na tym samym poziomie, których nazwy różnią się tylko w zależności od przypadku, zostaniesz uderzony przez to. Przeglądaj repozytorium źródłowe, korzystając z jego interfejsu WWW (np. GitHub lub VSTS), aby się upewnić.

Więcej informacji: https://stackoverflow.com/a/2016426/67824

Run clean Komenda:

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd

Sprawdź swoje .gitattributes.

W moim przypadku mam *.js text eol=lf w nim i opcja git core.autocrlf Była true.

Sprowadza mnie to do sytuacji, kiedy git automatycznie konwertuje zakończenia linii plików i uniemożliwia mi to naprawianie, a nawet git reset --hard HEAD nic nie zrobił.

Naprawiam to komentując *.js text eol=lf w moim .gitattributes i komentując po nim.

Możesz stash odkładaj swoje zmiany, a następnie upuść skrytkę:

git stash
git stash drop

Żadna z tych metod nie zadziałała, jedynym rozwiązaniem było zbombardowanie całego repo i ponowne sklonowanie go. Obejmuje to Przechowywanie, Resetowanie, dodawanie następnie Resetowanie, ustawienia clrf, czułość wielkości liter itp. Westchnienie..

Miałem ten sam problem. Zrobiłem git reset --hard HEAD, ale za każdym razem, gdy robiłem git status widziałem jakieś pliki jako zmodyfikowane.

Trafiłem na podobny problem również dotyczący .gitattributes, ale w moim przypadku dotyczy LFS Githuba. Chociaż nie jest to dokładnie scenariusz OP, myślę, że daje to okazję do zilustrowania tego, co robi plik .gitattributes i dlaczego może prowadzić do nieakceptowanych zmian w postaci różnic "fantomowych".

W moim przypadku plik był już w moim repozytorium, jak Od początku czasu. W ostatnim commicie dodałem nową regułę git-lfs track używając wzorca, który z perspektywy czasu był nieco zbyt szeroki i kończył się pasuje do tego starożytnego pliku. Wiem, że nie chciałem zmieniać tego pliku; wiem, że nie zmieniłem pliku, ale teraz był on w moich niestagowanych zmianach i żadna ilość kasowań lub twardych resetów w tym pliku nie miała go naprawić. Dlaczego?

Rozszerzenie GitHub LFS działa przede wszystkim poprzez wykorzystanie hooków, które git zapewniają dostęp poprzez plik .gitattributes. Ogólnie rzecz biorąc, wpisy w .gitattributes określają sposób przetwarzania pasujących plików. W przypadku PO chodziło o normalizację linii zakończenia; w moim było to, czy pozwolić LFS zająć się przechowywaniem plików. W obu przypadkach plik, który git widzi przy obliczaniu git diff, nie pasuje do pliku, który widzisz podczas sprawdzania pliku. W związku z tym, jeśli zmienisz sposób przetwarzania pliku za pomocą wzorca .gitattributes, który go pasuje, pojawi się on jako nieakstragowane zmiany w raporcie stanu, nawet jeśli naprawdę nie ma żadnych zmian w pliku.

Moja "odpowiedź" na pytanie jest taka, że jeśli zmiana w .gitattributes pliku jest coś, co chciałeś zrobić, powinieneś naprawdę dodać zmiany i iść dalej. Jeśli nie, zmień .gitattributes, aby lepiej reprezentować to, co chcesz robić.

Referencje

1. Specyfikacja GitHub LFS - świetny opis sposobu łączenia się z wywołaniami funkcji clean i smudge w celu zastąpienia pliku w obiektach git prostym plikiem tekstowym z Hashem.

2. Gitattributes Documentation - wszystkie szczegóły na temat tego, co jest dostępny, aby dostosować sposób git przetwarza dokumenty.

Uważam, że istnieje problem z git dla Windows, w którym Git losowo zapisuje błędne zakończenia linii przy kasie i jedynym obejściem jest wypisanie innej gałęzi i zmuszenie git do zignorowania zmian. Następnie sprawdź gałąź, nad którą chcesz pracować.

git checkout master -f
git checkout <your branch>

Pamiętaj, że spowoduje to odrzucenie wszelkich zmian, które mogłeś celowo wprowadzić, więc zrób to tylko wtedy, gdy masz ten problem natychmiast po kasie.

Edit: za pierwszym razem chyba mi się poszczęściło. Okazuje się, że znowu zostałem ugryziony po zmianie gałęzi. Okazało się, że pliki Git raportował jako zmodyfikowane po zmianie gałęzi. (Najwyraźniej dlatego, że git nie konsekwentnie stosował końcówki linii CRLF do plików poprawnie.)

Zaktualizowałem do najnowszej wersji git dla Windows i mam nadzieję, że problem zniknie.

Podobny problem, chociaż jestem pewien, że tylko na powierzchni. W każdym razie może komuś pomóc: co zrobiłem (FWIW, w SourceTree): schowałem plik, a następnie zrobiłem twardy reset.

Jak zauważyły inne odpowiedzi, problem jest spowodowany automatycznym korygowaniem linii. Napotkałem ten problem z *.plików svg. Używałem pliku svg do ikon w moim projekcie.

Aby rozwiązać ten problem, poinformowałem Gita, że pliki svg powinny być traktowane jako binarne zamiast tekstowe, dodając poniższą linię do .gitattributes

*.svg binary

Jeśli inne odpowiedzi nie działają, spróbuj dodać pliki, a następnie zresetuj

$ git add -A
$ git reset --hard

W moim przypadku pomogło to, gdy git śledził kilka pustych plików.

W podobnej sytuacji. W wyniku wielu lat męki z wieloma programistami, którzy byli w stanie wypchnąć różne kodowania końców linii (.asp ,.js,css ... nie esencję) w jednym pliku. Jakiś czas temu odmówił .gitattributes. Ustawienia dla repo left autorclf = true i safecrlf = warn.

Ostatni problem pojawił się podczas synchronizacji z archiwum z różnymi końcami linii. Po skopiowaniu z archiwum, w statusie git wiele plików jest zmienianych za pomocą Uwaga

The line will have its original line endings in your working directory. warning: LF will be replaced by CRLF in ...

Wskazówki z jak normalizować działające zakończenia linii drzewa w Git? pomógł

git add -u