status git pokazuje modyfikacje, git checkout - <plik> nie usuwa ich

Chciałbym usunąć wszystkie zmiany w mojej kopii roboczej.
Uruchamianie git statuspokazuje zmodyfikowane pliki.
Nic, co robię, nie usuwa tych modyfikacji.
Na przykład:

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")

Istnieje wiele problemów, które mogą powodować takie zachowanie:

Normalizacja zakończenia linii

Miałem też tego rodzaju problemy. Sprowadza się to do git automatycznie konwertującego crlf na lf. Jest to zwykle spowodowane mieszanymi zakończeniami linii w jednym pliku. Plik normalizuje się w indeksie, ale gdy git następnie go normalizuje, aby różnicować go względem pliku w drzewie roboczym, wynik jest inny.

Ale jeśli chcesz to naprawić, powinieneś wyłączyć core.autocrlf , zmienić wszystkie zakończenia linii na lf, a następnie włączyć je ponownie. Możesz też całkowicie wyłączyć, wykonując:

git config --global core.autocrlf false

Zamiast core.autocrlf możesz również rozważyć użycie .gitattributeplików. W ten sposób możesz upewnić się, że wszyscy korzystający z repozytorium stosują te same reguły normalizacji, zapobiegając dostawaniu się mieszanych zakończeń linii do repozytorium.

Zastanów się również nad ustawieniem core.safecrlf, aby ostrzegał, jeśli chcesz, aby git ostrzegał cię przed wykonaniem nieodwracalnej normalizacji.

GIT manpages powiedzieć to:

Konwersja CRLF ma niewielką szansę na uszkodzenie danych. autocrlf = true przekonwertuje CRLF na LF podczas zatwierdzania i LF na CRLF podczas realizacji transakcji. Plik zawierający mieszaninę LF i CRLF przed zatwierdzeniem nie może zostać odtworzony przez git. W przypadku plików tekstowych jest to słuszne: poprawia zakończenia linii tak, że w repozytorium mamy tylko zakończenia linii LF. Ale w przypadku plików binarnych przypadkowo sklasyfikowanych jako tekst konwersja może uszkodzić dane.

Systemy plików bez rozróżniania wielkości liter

W systemach plików bez rozróżniania wielkości liter, w repozytorium znajduje się ta sama nazwa pliku z inną obudową, git próbuje pobrać oba, ale tylko jeden kończy się w systemie plików. Gdy git próbuje porównać drugi, porówna go z niewłaściwym plikiem.

Rozwiązaniem byłoby albo przejście na system plików bez rozróżniania wielkości liter, ale w większości przypadków nie jest to wykonalne lub zmiana nazwy i zatwierdzenie jednego z plików w innym systemie plików.

Miałem ten problem w systemie Windows, ale nie byłem przygotowany na przyjrzenie się konsekwencjom używania. config --global core.autocrlf falseNie byłem również przygotowany na porzucenie innych prywatnych gałęzi i gadżetów w mojej skrytce i rozpoczęcie od nowego klonu. Po prostu muszę coś zrobić. Teraz.

Dla mnie to zadziałało, ponieważ pozwoliłeś git całkowicie przepisać katalog roboczy:

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

(Zwróć uwagę, że uruchamianie git reset --hardnie było wystarczająco dobre, ani też nie było zwykłych rmplików przed, resetjak sugerują komentarze w pierwotnym pytaniu)

Inne rozwiązanie, które może działać dla ludzi, ponieważ żadna z opcji tekstowych nie działała dla mnie:

1. Wymień zawartość .gitattributesz jednej linii: * binary. To mówi gitowi, aby traktował każdy plik jako plik binarny, z którym nic nie może zrobić.
2. Sprawdź, czy wiadomość dotycząca szkodliwych plików zniknęła; jeśli nie, możesz git checkout -- <files>przywrócić je do wersji repozytorium
3. git checkout -- .gitattributesaby przywrócić .gitattributesplik do stanu początkowego
4. Sprawdź, czy pliki nadal nie są oznaczone jako zmienione.

Dla przyszłych osób mających ten problem: zmiany w trybie pliku mogą mieć te same objawy. git config core.filemode falsenaprawi to.

Doprowadzało mnie to do szaleństwa, zwłaszcza że nie mogłem tego naprawić bez żadnego rozwiązania znalezionego online. Oto jak to rozwiązałem. Nie mogę wziąć kredytów tutaj, ponieważ jest to praca kolegi :)

Źródło problemu: Moja początkowa instalacja git była bez automatycznej konwersji linii w systemie Windows. To spowodowało, że moje początkowe zaangażowanie w GLFW było bez właściwego zakończenia linii.

Uwaga: jest to tylko rozwiązanie lokalne. Kolejny facet klonujący repo nadal będzie miał problem z tym problemem. Stałe rozwiązanie można znaleźć tutaj: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository .

Instalacja: Xubuntu 12.04 Git repo z projektem glfw

Problem: Nie można zresetować plików glfw. Zawsze pokazują się jako zmodyfikowane, niezależnie od tego, co próbowałem.

Rozwiązany:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Miałem plik .bat z tym samym problemem (nie mogłem się go pozbyć w nieśledzonych plikach). git checkout - nie działał, żadna z sugestii na tej stronie nie działała. Jedyne, co działało dla mnie, to:

git stash save --keep-index

A następnie, aby usunąć skrytkę:

git stash drop

Mam ten sam problem dwa razy! Za każdym razem, gdy ukrywałem niektóre zmiany, które wprowadziłem, a następnie próbowałem je wycofać. Nie można usunąć zmian, ponieważ mam wiele plików, które zostały zmienione - ale NIE są! Są DOKŁADNIE takie same.

Myślę, że wypróbowałem wszystkie powyższe rozwiązania bez powodzenia. Po wypróbowaniu

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

Mam teraz prawie wszystkie pliki w moim repozytorium zmodyfikowane.

Podczas różnicowania pliku jest napisane, że usunąłem wszystkie linie, a następnie dodałem je ponownie.

Trochę niepokojące. W przyszłości uniknę ukrywania się.

Jedynym rozwiązaniem jest sklonowanie nowego repozytorium i rozpoczęcie od nowa. (Zrobił to ostatni raz)

Spróbuj zrobić

git checkout -f

To powinno usunąć wszystkie zmiany w bieżącym działającym repozytorium lokalnym

Byłem w stanie to naprawić tylko tymczasowo usuwając plik .gitattributes mojego repozytorium (który zdefiniował * text=autoi *.c text).

Pobiegłem git statuspo usunięciu i zmiany zniknęły. Nie wrócili nawet po przywróceniu .gitattributes.

Dobrze jest mieć spójne zakończenia linii. Na przykład nie spowoduje to niepotrzebnych połączeń, choć banalne. Widziałem, jak program Visual Studio tworzy pliki z mieszanymi zakończeniami linii.

Również niektóre programy, takie jak bash (na Linuksie), wymagają, aby pliki .sh były zakończone w LF.

Aby się upewnić, że tak się stanie, możesz użyć gitattributes. Działa na poziomie repozytorium bez względu na wartość autcrlf.

Na przykład możesz mieć .gitattributes takie jak to: * text = auto

Możesz także sprecyzować typ / rozszerzenie pliku, jeśli miało to znaczenie w twoim przypadku.

Następnie autocrlf może konwertować lokalnie zakończenia linii dla programów Windows.

W mieszanym projekcie C # / C ++ / Java / Ruby / R, Windows / Linux działa to dobrze. Jak dotąd żadnych problemów.

Miałem te same objawy, ale zostały spowodowane przez inną rzecz.

Nie byłem w stanie:

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

nawet na git rm --cached app.jsnim podpisuje się jako usunięty, aw nie śledzonych plikach widziałem app.js. Ale kiedy spróbowałem rm -rf app.jsi wykonałem git statusponownie, nadal pokazuje mi plik w „nieśledzonym”.

Po kilku próbach z kolegą okazało się, że jest to spowodowane przez Grunta!

Po Gruntwłączeniu i ponieważ app.js został wygenerowany z kilku innych plików js, dowiedzieliśmy się, że po każdej operacji z plikami js (także ta aplikacja.js) grunt ponownie odtwarza app.js.

Ten problem może również wystąpić, gdy współtwórca repozytorium działa na komputerze z systemem Linux lub zmieniane są okna z Cygwin i uprawnienia do plików. Git wie tylko o 755 i 644.

Przykład tego problemu i sposób jego sprawdzenia:

git diff styleguide/filename

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

Aby tego uniknąć, upewnij się, że poprawnie skonfigurowałeś git

git config --global core.filemode false

Jest tu wiele rozwiązań i być może powinienem był wypróbować niektóre z nich, zanim wymyślę własne. W każdym razie tutaj jest jeszcze jeden ...

Naszym problemem było to, że nie mieliśmy wymuszania linii końcowych, a repozytorium zawierało mieszankę DOS / Unix. Jeszcze gorsze było to, że w tej pozycji było to repozytorium open source, które rozwinęliśmy. Podmioty decydujące o pierwotnym posiadaniu repozytorium systemu operacyjnego podjęły decyzję o zmianie wszystkich linii końcowych na uniksowe i dokonano zatwierdzenia, które obejmowało a, .gitattributesaby wymusić zakończenie linii.

Niestety zdawało się to powodować problemy podobne do opisanych tutaj, w których po scaleniu kodu sprzed DOS-2-Unix pliki były na zawsze oznaczone jako zmienione i nie można ich było przywrócić.

Podczas moich badań natknąłem się na - https://help.github.com/articles/dealing-with-line-endings/ - Jeśli znów napotkam ten problem, zacznę od wypróbowania tego.

Oto co zrobiłem:

1. Początkowo dokonałem scalenia, zanim zdałem sobie sprawę, że mam ten problem i musiałem przerwać - git reset --hard HEAD( wpadłem w konflikt scalania. Jak mogę przerwać scalanie? )

2. Otworzyłem te pliki w VIM i zmieniłem na Unix ( :set ff=unix). dos2unixOczywiście można użyć takiego narzędzia

3. zobowiązany

4. scalono masterw (master ma zmiany DOS-2-Unix)

   git checkout old-code-branch; git merge master

5. Rozwiązane konflikty i pliki były ponownie DOS, więc musiało to być :set ff=unixw VIM. (Uwaga: Zainstalowałem https://github.com/itchyny/lightline.vim, co pozwoliło mi zobaczyć, jaki format pliku znajduje się na linii statusu VIM)

6. zobowiązany. Wszystko posortowane!

Problemem, na który natknąłem się, jest to, że Windows nie dba o wielkie litery, ale git ma. Więc git zapisał małą i wielką wersję pliku, ale mógł tylko pobrać jedną.

Zatwierdziłem wszystkie zmiany, a następnie zrobiłem i cofnąłem zatwierdzenie. To zadziałało dla mnie

git add.

git commit -m „Losowe zatwierdzenie”

git reset - twarda GŁOWA ~ 1

Zwykle w GIT, aby usunąć wszystkie modyfikacje i nowe pliki, następujące 2 polecenia powinny działać bardzo ładnie (bądź ostrożny , spowoduje to usunięcie wszystkich twoich nowych plików + folderów, które mogłeś utworzyć i przywróci wszystkie zmodyfikowane pliki do stanu bieżącego zatwierdzenie ):

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

Może czasem lepszym rozwiązaniem jest po prostu wykonanie polecenia „git stash push” z opcjonalnym komunikatem:

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

Spowoduje to również wyczyszczenie wszystkich nowych i zmodyfikowanych plików, ale wszystkie zostaną ukryte na wypadek, gdybyś chciał je przywrócić. Skrytka w GIT przenosi się z gałęzi do gałęzi, więc możesz przywrócić je w innej gałęzi, jeśli chcesz.

Na marginesie, jeśli już przygotowałeś niektóre nowo dodane pliki i chcesz się ich pozbyć, powinno to załatwić sprawę:

$ git reset --hard

Jeśli to wszystko nie działa , przeczytaj poniżej, co działało dla mnie jakiś czas temu:

Kilka razy wcześniej napotkałem ten problem. Obecnie rozwijam się na maszynie Windows 10 dostarczonej przez mojego pracodawcę. Dzisiaj to szczególne zachowanie git zostało spowodowane przez utworzenie nowej gałęzi z mojej gałęzi „rozwijania”. Z jakiegoś powodu, po tym, jak wróciłem do gałęzi „rozwijania”, niektóre pozornie przypadkowe pliki pozostały i były wyświetlane jako „zmodyfikowane” w „statusie git”.

Ponadto w tym momencie nie mogłem sprawdzić innej gałęzi, więc utknąłem na mojej gałęzi „rozwijania”.

Oto co zrobiłem:

$ git log

Zauważyłem, że nowa gałąź, którą utworzyłem dzisiaj z „rozwijania”, pokazywała się w pierwszym komunikacie „zatwierdzenia”, na końcu na końcu „HEAD -> rozwijanie, pochodzenie / rozwijanie, pochodzenie / HEAD, gałąź-i-utworzone - wcześniej-dziś ”.

Ponieważ tak naprawdę go nie potrzebowałem, usunąłem go:

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

Zmienione pliki wciąż się wyświetlały, więc zrobiłem:

$ git stash

To rozwiązało mój problem:

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

nothing to commit, working tree clean

Oczywiście $ git stash listpokaże ukryte zmiany, a ponieważ miałem ich niewiele i nie potrzebowałem żadnych $ git stash clearskrytek, usunąłem WSZYSTKIE SKŁADKI.

UWAGA : nie próbowałem robić tego, co ktoś mi tutaj zasugerował:

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

Mogło to również zadziałać, na pewno wypróbuję to następnym razem, gdy napotkam ten problem.

Jeśli sklonujesz repozytorium i natychmiast zobaczysz oczekujące zmiany, to repozytorium jest w niespójnym stanie. Proszę NIE komentować * text=autoz .gitattributespliku. Stało się tak właśnie dlatego, że właściciel repozytorium chce, aby wszystkie pliki były przechowywane spójnie z zakończeniami linii LF.

Jak stwierdził HankCa, postępowanie zgodnie z instrukcjami na https://help.github.com/articles/dealing-with-line-endings/ jest sposobem na rozwiązanie problemu. Łatwy przycisk:

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

Następnie scal (lub ściągnij) oddział z właścicielem repozytorium.

Nic więcej na tej stronie nie działało. To w końcu zadziałało dla mnie. Nie pokazuję żadnych nieśledzonych ani zatwierdzonych plików.

git add -A
git reset --hard

Dla mnie problemem było to, że Visual Studio zostało otwarte podczas wykonywania polecenia

git checkout <file>

Po zamknięciu programu Visual Studio polecenie zadziałało i mogłem w końcu zastosować moją pracę ze stosu. Sprawdź więc wszystkie aplikacje, które mogą wprowadzać zmiany w kodzie, na przykład SourceTree, SmartGit, NotePad, NotePad ++ i inne edytory.

W naszej firmie mieliśmy podobną sytuację. Żadna z proponowanych metod nam nie pomogła. W wyniku badań problem został ujawniony. Chodziło o to, że w Git były dwa pliki, których nazwy różniły się tylko rejestrem symboli. Systemy uniksowe widziały je jako dwa różne pliki, ale Windows oszalał. Aby rozwiązać problem, usunęliśmy jeden z plików na serwerze. Następnie w lokalnych repozytoriach w systemie Windows pomogło kilka kolejnych poleceń (w różnych sekwencjach):

git reset --hard
git pull origin
git merge

Rozwiązałem to, edytując .git / config, dodając:

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

Potem poszedłem do .git / refs / heads / name_branch i umieściłem identyfikator ostatniego zatwierdzeniaenter code here

Rozwiązałem to w ten sposób:

1. Skopiuj zawartość poprawnego kodu, który chcesz
2. Usuń z dysku plik powodujący problem (ten, którego nie można przywrócić). teraz powinieneś znaleźć obie wersje tego samego pliku oznaczone jako usunięte.
3. Zatwierdź usunięcie plików.
4. Utwórz plik ponownie o tej samej nazwie i wklej poprawny kod skopiowany w kroku 1
5. zatwierdzić utworzenie nowego pliku.

To działało dla mnie.

Jedno zaproponowane rozwiązanie tutaj nie zadziałało, dowiedziałem się, że plik był tak naprawdę linkiem do niektórych znaków specjalnych:

% 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