web-dev-qa-db-de.com

git status zeigt Änderungen an, git checkout - <file> entfernt sie nicht

Ich möchte alle Änderungen an meiner Arbeitskopie entfernen.
Beim Ausführen von git status werden die geänderten Dateien angezeigt.
Nichts scheint diese Modifikationen zu entfernen.
Z.B.:

[email protected] /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")

[email protected] /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

[email protected] /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")

[email protected] /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

[email protected] /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")

[email protected] /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.

[email protected] /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")
194
rbellamy

Es gibt mehrere Probleme, die dieses Verhalten verursachen können:

Zeilenende-Normalisierung

Ich hatte auch solche Probleme. Es kommt darauf an, dass git automatisch crlf in lf konvertiert. Dies wird normalerweise durch gemischte Zeilenenden in einer einzelnen Datei verursacht. Die Datei wird im Index normalisiert, aber wenn git denormalisiert, um sie mit der Datei im Arbeitsbaum zu vergleichen, ist das Ergebnis anders.

Wenn Sie dies beheben möchten, sollten Sie core.autocrlf deaktivieren, alle Zeilenenden in lf ändern und sie dann erneut aktivieren. Oder Sie können es ganz deaktivieren, indem Sie Folgendes tun:

git config --global core.autocrlf false

Anstelle von core.autocrlf können Sie auch die Verwendung von .gitattribute files in Betracht ziehen. Auf diese Weise können Sie sicherstellen, dass alle, die das Repo verwenden, dieselben Normalisierungsregeln verwenden, um zu verhindern, dass gemischte Zeilenenden in das Repository gelangen.

Erwägen Sie auch die Einstellung core.safecrlf, um zu warnen, wenn git Sie warnen soll, wenn eine nicht reversible Normalisierung durchgeführt wird.

Die git manpages sagen folgendes:

Die CRLF-Konvertierung hat eine geringe Chance von beschädigten Daten. autocrlf = true wird Konvertieren Sie CRLF während Commit und .__ in LF. LF an CRLF während des Bezahlvorgangs. Eine Datei das enthält eine Mischung aus LF und CRLF bevor das Festschreiben nicht erneut erstellt werden kann von git. Für Textdateien ist dies das Richtiges zu tun: Es korrigiert die Zeile Endungen, so dass wir nur die Zeile LF haben Endungen im Repository. Aber für Binärdateien, die versehentlich .__ sind. Die Konvertierung kann als Text klassifiziert werden beschädigte Daten.

Dateisysteme ohne Berücksichtigung der Groß- und Kleinschreibung

Wenn bei Dateisystemen, bei denen die Groß- und Kleinschreibung nicht beachtet wird, derselbe Dateiname mit anderem Gehäuse im Repository vorhanden ist, versucht git, beide zu überprüfen, aber nur einer landet im Dateisystem. Wenn git versucht, die zweite zu vergleichen, wird sie mit der falschen Datei verglichen.

Die Lösung würde entweder auf ein nicht-case-abhängiges Dateisystem umstellen, dies ist jedoch in den meisten Fällen nicht machbar oder es wird eine der Dateien in einem anderen Dateisystem umbenannt und festgelegt.

116
Ikke

Ich hatte dieses Problem unter Windows, war aber nicht bereit, die Auswirkungen der Verwendung von config --global core.autocrlf false zu untersuchen. Ich war auch nicht bereit, andere private Filialen und Goodies in meinem Vorrat aufzugeben und mit einem neuen Klon zu beginnen. Ich muss nur etwas erledigen. Jetzt.

Dies funktionierte für mich auf der Idee, dass Sie git Ihr Arbeitsverzeichnis komplett neu schreiben lassen:

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

(Beachten Sie, dass das Ausführen von nur git reset --hard nicht gut genug war oder eine einfache rm in den Dateien vor der reset war, wie in den Kommentaren zur ursprünglichen Frage vorgeschlagen.)

182
Rian Sanderson

Eine andere Lösung, die möglicherweise für Menschen geeignet ist, da keine der Textoptionen für mich funktioniert hat:

  1. Ersetzen Sie den Inhalt von .gitattributes durch eine einzige Zeile: * binary. Dies weist git an, jede Datei als eine binäre Datei zu behandeln, mit der sie nichts anfangen kann.
  2. Überprüfen Sie, ob die Nachricht für die fehlerhaften Dateien verschwunden ist. Wenn dies nicht der Fall ist, können Sie git checkout -- <files> verwenden, um sie in der Repository-Version wiederherzustellen
  3. git checkout -- .gitattributes, um die .gitattributes-Datei in ihren ursprünglichen Zustand zurückzusetzen
  4. Stellen Sie sicher, dass die Dateien immer noch nicht als geändert markiert sind.
86
zebediah49

Für zukünftige Personen, die dieses Problem haben: Die Änderung des Dateimodus kann dieselben Symptome haben. git config core.filemode false wird das Problem beheben.

66
Marty Neal

Das hat mich wahnsinnig gemacht, vor allem, dass ich dies ohne die online gefundenen Lösungen nicht beheben konnte. So habe ich es gelöst. Ich kann den Abspann hier nicht machen, da dies die Arbeit eines Kollegen ist :)

Ursache des Problems: Meine erste Installation von git war ohne automatische Zeilenumwandlung unter Windows. Dies hatte zur Folge, dass meine ursprüngliche Zusage an GLFW ohne die richtige Zeilenbeendigung war.

Hinweis: Dies ist nur eine lokale Lösung. Der nächste Typ, der das Repo kloniert wird immer noch mit diesem Problem stecken. Eine dauerhafte Lösung kann sein hier gefunden: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository .

Setup: Xubuntu 12.04 Git-Repo mit glfw-Projekt

Problem: glfw-Dateien können nicht zurückgesetzt werden. Sie werden immer als modifiziert angezeigt, unabhängig davon, was ich versucht habe.

Gelöst:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes
30

Ich hatte eine .bat-Datei mit dem gleichen Problem (konnte es nicht in ungespurten Dateien loswerden). git checkout - hat nicht funktioniert, auch keiner der Vorschläge auf dieser Seite. Das einzige, was für mich funktionierte, war zu tun:

git stash save --keep-index

Und dann den Stash löschen:

git stash drop
11
moo moo

Ich habe zweimal dieselbe Ausgabe! Beide Male, als ich einige Änderungen vornahm, versuchte ich sie zurückzudrehen. Die Änderungen konnten nicht eingeblendet werden, da ich viele Dateien geändert habe - aber NICHT! Sie sind genau das gleiche.

Ich denke jetzt, dass ich alle obigen Lösungen ohne Erfolg ausprobiert habe. Nach dem Ausprobieren 

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

Ich habe jetzt fast alle Dateien in meinem Repository geändert. 

Wenn die Datei unterschiedlich ist, werden alle Zeilen gelöscht und dann wieder hinzugefügt.

Irgendwie beunruhigend. Ich werde jetzt in Zukunft nicht mehr verstauen.

Die einzige Lösung ist, ein neues Repository zu klonen und neu zu beginnen. (Letztes Mal gemacht)

5
Fam Wired

Ich konnte dies nur beheben, indem ich die .gitattributes-Datei meines Repos (die * text=auto und *.c text definierte) vorübergehend löschte.

Ich löschte git status nach dem Löschen und die Änderungen waren weg. Sie kehrten auch nicht zurück, nachdem .gitattributes wieder eingesetzt wurde.

4
Artfunkel

Hier gibt es viele Lösungen, und ich hätte vielleicht einige davon ausprobieren sollen, bevor ich meine eigenen gefunden habe. Jedenfalls ist hier noch eine ...

Unser Problem war, dass wir für Endlines keine Durchsetzung hatten und das Repository eine Mischung aus DOS/Unix hatte. Noch schlimmer war jedoch, dass es sich in dieser Position tatsächlich um ein Open Source-Repo handelte, das wir gegabelt hatten. Die Entscheidung wurde von den primären Eigentümern des OS-Repositorys getroffen, um alle Endlines in Unix zu ändern, und das Commit wurde mit einem .gitattributes zur Durchsetzung der Zeilenenden vorgenommen.

Unglücklicherweise verursachte dies Probleme, ähnlich wie hier beschrieben, wo die Dateien nach dem Zusammenführen von Code vor dem DOS-2-Unix für immer als geändert markiert wurden und nicht mehr rückgängig gemacht werden konnten.

Bei meiner Recherche stieß ich auf - https://help.github.com/articles/dealing-with-line-endings/ - Wenn ich dieses Problem noch einmal sehe, würde ich es zuerst versuchen das heraus.


Folgendes habe ich getan:

  1. Ich hatte anfangs eine Zusammenführung vorgenommen, bevor mir klar wurde, dass ich dieses Problem hatte, und musste das Problem abbrechen - git reset --hard HEAD ( Ich bin in einen Zusammenführungskonflikt geraten. Wie kann ich die Zusammenführung abbrechen? )

  2. Ich habe die betreffenden Dateien in VIM geöffnet und in Unix (:set ff=unix) geändert. Ein Tool wie dos2unix kann natürlich auch verwendet werden

  3. engagiert sein

  4. master in zusammengefügt (der Master hat die Änderungen von DOS-2-Unix)

    git checkout old-code-branch; git merge master

  5. Konflikte wurden behoben und die Dateien wurden wieder unter DOS, sodass :set ff=unix in VIM erforderlich war. (Hinweis: Ich habe https://github.com/itchyny/lightline.vim installiert, wodurch ich das Dateiformat in der Statuszeile VIM sehen kann.

  6. engagiert sein. Alles sortiert!
2
HankCa

Konsequente Zeilenenden zu haben, ist eine gute Sache. Zum Beispiel wird es keine unnötigen, wenn auch unbedeutenden Zusammenführungen auslösen. Ich habe gesehen, wie Visual Studio Dateien mit gemischten Zeilenenden erstellt.

Für einige Programme wie bash (unter Linux) ist es jedoch erforderlich, dass .sh-Dateien LF beendet werden.

Um sicherzustellen, dass dies geschieht, können Sie gitattributes verwenden. Es funktioniert auf Repository-Ebene, unabhängig davon, welchen Wert Autcrlf hat.

So können Sie beispielsweise .gitattributes haben: * text = auto

Sie können auch spezifischer pro Dateityp/-erweiterung sein, wenn dies in Ihrem Fall von Bedeutung ist.

Autocrlf kann dann Zeilenenden für Windows-Programme lokal konvertieren.

Bei einem gemischten C #/C++/Java/Ruby/R-Projekt unter Windows/Linux funktioniert dies gut. Bisher keine Probleme.

2
dpiskyulev

Ich hatte auch die gleichen Symptome, wurde aber durch eine andere Sache verursacht.

Ich war nicht in der Lage zu:

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

selbst auf git rm --cached app.js unterschreibt es als gelöscht, und in nicht protokollierten Dateien konnte ich app.js. sehen. Wenn ich jedoch rm -rf app.js und peform git status erneut ausprobiert habe, wird mir die Datei immer noch in 'untracked' angezeigt.

Nach ein paar Versuchen mit Kollegen haben wir herausgefunden, dass Grunt es verursacht hat!

Da Grunt eingeschaltet ist und app.js aus einigen anderen js-Dateien generiert wurde, haben wir festgestellt, dass nach jeder Operation mit js-Dateien (auch diese app.js) app.js erneut erstellt wird.

2
Nedvajz

Dieses Problem kann auch auftreten, wenn ein Mitarbeiter des Repos auf einem Linux-Computer funktioniert oder Fenster mit Cygwin und Dateiberechtigungen geändert werden. Git kennt nur 755 und 644.

Beispiel für dieses Problem und wie Sie es prüfen können:

git diff styleguide/filename

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

Um dies zu vermeiden, sollten Sie sicherstellen, dass Sie mit git richtig eingerichtet haben

git config --global core.filemode false
1
bg17aw

Für mich bestand das Problem darin, dass Visual Studio beim Ausführen des Befehls geöffnet wurde 

git checkout <file>

Nach dem Schließen von Visual Studio klappte der Befehl und ich konnte meine Arbeit endlich vom Stapel anwenden. Überprüfen Sie daher alle Anwendungen, die Änderungen an Ihrem Code vornehmen könnten, beispielsweise SourceTree, SmartGit, NotePad, NotePad ++ und andere Editoren.

1
Jesper Lundin

Wenn Sie ein Repository klonen und sofort ausstehende Änderungen sehen, befindet sich das Repository in einem inkonsistenten Zustand. Bitte kommentieren Sie NICHT * text=auto aus der .gitattributes-Datei aus. Das wurde speziell dort eingefügt, weil der Besitzer des Repositorys alle Dateien konsistent mit LF - Zeilenenden speichern möchte. 

Wie von HankCa festgestellt, ist das Befolgen der Anweisungen unter https://help.github.com/articles/dealing-with-line-endings/ der Weg, um das Problem zu beheben. Einfache Taste:

git clone [email protected]: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

Dann den Zweig mit dem Besitzer des Repos zusammenführen (oder Pull-Request).

1
w25r

Das Problem, dem ich begegnet bin, ist, dass Windows sich nicht für die Dateinamen-Großschreibung interessiert, aber bei git. So speicherte git eine Klein- und Großbuchstabenversion der Datei, konnte aber nur eine auschecken.

1
xaav

In unserem Unternehmen waren wir mit einer ähnlichen Situation konfrontiert. Keine der vorgeschlagenen Methoden hat uns nicht geholfen. Als Ergebnis der Forschung wurde das Problem aufgedeckt. Die Sache war die, dass es in Git zwei Dateien gab, deren Namen sich nur im Symbolregister unterschieden. Unix-Systeme sahen sie als zwei verschiedene Dateien an, aber Windows wurde verrückt. Um das Problem zu lösen, haben wir eine der Dateien auf dem Server gelöscht. Danach haben in den lokalen Repositorys unter Windows die nächsten Befehle (in verschiedenen Sequenzen) geholfen:

git reset --hard
git pull Origin
git merge
0
bside

Ich bin schon einige Male auf dieses Problem gestoßen. Ich entwickle derzeit auf einem Windows 10-Computer, der von meinem Arbeitgeber bereitgestellt wird. Dieses besondere Git-Verhalten wurde heute dadurch verursacht, dass ich aus meinem "Develop" -Zweig einen neuen Zweig erstellt habe. Aus irgendeinem Grund blieben einige scheinbar zufällige Dateien bestehen, nachdem ich zum Zweig "Entwickeln" zurückgekehrt war, und wurden im "Git-Status" als "Geändert" angezeigt.

Außerdem konnte ich zu diesem Zeitpunkt keinen anderen Zweig auschecken, sodass ich auf meinem Zweig "Entwickeln" feststeckte.

Das habe ich gemacht:

$ git log

Mir ist aufgefallen, dass der neue Zweig, den ich heute mit "Develop" erstellt habe, in der ersten "Commit" -Nachricht angezeigt wurde und am Ende mit "HEAD -> Develop, Origin/Develop, Origin/HEAD, The-branch -i-früher-heute erstellt ".

Da ich es nicht wirklich brauchte, habe ich es gelöscht:

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

Die geänderten Dateien wurden immer noch angezeigt, also habe ich Folgendes getan:

$ git stash

Dies löste mein Problem:

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

nothing to commit, working tree clean

Natürlich $ git stash list zeigt versteckte Änderungen an, und da ich nur wenige hatte und keine meiner Verstecke brauchte, habe ich $ git stash clear, um ALLE STASHES ZU LÖSCHEN.

NOTE : Ich habe nicht versucht, das zu tun, was hier jemand vor mir vorgeschlagen hat:

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

Möglicherweise hat dies auch funktioniert. Ich werde es beim nächsten Mal versuchen, wenn ich auf dieses Problem stoße.

0
derekg

Ich löste es durch Editieren von .git/config und fügte hinzu:

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

Dann ging ich zu .git/refs/heads/name_branch Und gebe die ID des letzten Commitsenter code here

0

Versuchen Sie es mit einem 

git checkout -f 

Damit sollten alle Änderungen im aktuellen lokalen Repo gelöscht werden 

0
nsg

Ich habe alle Änderungen übernommen und das Commit dann rückgängig gemacht und rückgängig gemacht

git add.

git commit -m "Zufälliges Commit"

git reset --hard HEAD ~ 1

0
gcs06

Ich habe es so gelöst:

  1. Kopieren Sie den Inhalt des gewünschten Codes
  2. Löschen Sie die Datei, die das Problem verursacht (die Sie nicht wiederherstellen können) von Ihrer Festplatte. Jetzt sollten Sie beide Versionen derselben Datei als gelöscht markieren.
  3. Bestätigen Sie das Löschen der Dateien.
  4. Erstellen Sie die Datei erneut mit demselben Namen und fügen Sie den korrekten Code ein, den Sie in Schritt 1 kopiert haben
  5. bestätigen Sie die Erstellung der neuen Datei.

Das hat bei mir funktioniert.

0
M41k Dev3lops

Nichts anderes auf dieser Seite hat funktioniert. Das hat endlich für mich funktioniert. Es werden keine nicht protokollierten oder festgeschriebenen Dateien angezeigt. 

git add -A
git reset --hard
0
Philip Rego