Der Git-Status zeigt Änderungen an, der Git-Checkout - <Datei> entfernt sie nicht

Ich möchte alle Änderungen an meiner Arbeitskopie entfernen.
Beim Ausführen git statuswerden geänderte Dateien angezeigt.
Nichts, was ich tue, scheint diese Änderungen zu entfernen.
Z.B:

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

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

Normalisierung des Zeilenendes

Ich hatte auch solche Probleme. Es kommt darauf an, dass gl 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 sie dann erneut denormalisiert, um sie von der Datei im Arbeitsbaum zu unterscheiden, ist das Ergebnis anders.

Wenn Sie dies jedoch beheben möchten, sollten Sie core.autocrlf deaktivieren , alle Zeilenenden in lf ändern und 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 .gitattributeDateien verwenden. Auf diese Weise können Sie sicherstellen, dass jeder, der das Repo verwendet, dieselben Normalisierungsregeln verwendet, um zu verhindern, dass gemischte Zeilenenden in das Repository gelangen.

Ziehen Sie auch in Betracht, core.safecrlf als Warnung festzulegen , wenn git Sie warnen soll, wenn eine nicht umkehrbare Normalisierung durchgeführt wird.

Die Git- Manpages sagen Folgendes :

Bei der CRLF-Konvertierung besteht eine geringe Wahrscheinlichkeit, dass Daten beschädigt werden. autocrlf = true konvertiert CRLF während des Festschreibens in LF und LF in CRLF während des Auscheckens. Eine Datei, die vor dem Festschreiben eine Mischung aus LF und CRLF enthält, kann von git nicht neu erstellt werden. Für Textdateien ist dies das Richtige: Es korrigiert Zeilenenden so, dass nur LF-Zeilenenden im Repository vorhanden sind. Bei Binärdateien, die versehentlich als Text klassifiziert wurden, kann die Konvertierung jedoch Daten beschädigen.

Dateisysteme, bei denen die Groß- und Kleinschreibung nicht berücksichtigt wird

Bei Dateisystemen, bei denen die Groß- und Kleinschreibung nicht berücksichtigt wird, versucht git, beide Dateien auszuchecken, wenn sich derselbe Dateiname mit einem anderen Gehäuse im Repository befindet, aber nur eines landet im Dateisystem. Wenn git versucht, die zweite zu vergleichen, wird sie mit der falschen Datei verglichen.

Die Lösung wäre entweder, auf ein Dateisystem ohne Berücksichtigung der Groß- und Kleinschreibung zu wechseln, dies ist jedoch in den meisten Fällen nicht möglich, oder das Umbenennen und Festschreiben einer der Dateien in einem anderen Dateisystem.

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

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

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

(Beachten Sie, dass das Ausführen git reset --hardnicht gut genug war rmund die Dateien vor dem, resetwie in den Kommentaren zur ursprünglichen Frage vorgeschlagen, nicht eindeutig waren. )

Eine andere Lösung, die für Menschen funktionieren kann, da keine der Textoptionen für mich funktioniert hat:

1. Ersetzen Sie den Inhalt von .gitattributesdurch eine einzelne Zeile : * binary. Dies weist git an, jede Datei als Binärdatei zu behandeln, mit der es nichts anfangen kann.
2. Überprüfen Sie, ob die Meldung für die fehlerhaften Dateien nicht mehr vorhanden ist. Wenn dies nicht der Fall ist, können Sie git checkout -- <files>sie in der Repository-Version wiederherstellen
3. git checkout -- .gitattributesum die .gitattributesDatei in ihren Ausgangszustand zurückzusetzen
4. Stellen Sie sicher, dass die Dateien immer noch nicht als geändert markiert sind.

Für zukünftige Menschen mit diesem Problem: Änderungen im Dateimodus können dieselben Symptome haben. git config core.filemode falsewird es beheben.

Das hat mich verrückt gemacht, vor allem, dass ich dies ohne eine der online gefundenen Lösungen nicht beheben könnte. Hier ist, wie ich es gelöst habe. Ich kann die Credits hier nicht nehmen, da dies die Arbeit eines Kollegen ist :)

Ursache des Problems: Meine Erstinstallation von git war ohne automatische Zeilenkonvertierung unter Windows. Dies führte dazu, dass mein anfängliches Commit für GLFW ohne das richtige Zeilenende war.

Hinweis: Dies ist nur eine lokale Lösung. Der nächste Typ, der das Repo klont, wird immer noch mit diesem Problem konfrontiert sein. Eine dauerhafte Lösung finden Sie hier: 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

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

git stash save --keep-index

Und dann, um den Stash zu löschen:

git stash drop

Habe zweimal das gleiche Problem! Beide Male, als ich einige Änderungen gespeichert habe, habe ich versucht, sie zurückzuschieben. Die Änderungen konnten nicht eingefügt werden, da ich viele geänderte Dateien habe - aber sie sind NICHT! Sie sind genau gleich.

Ich denke jetzt, ich habe alle oben genannten Lösungen ohne Erfolg ausprobiert. Nach dem Versuch der

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

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

Wenn Sie die Datei unterscheiden, heißt es, dass ich alle Zeilen gelöscht und sie dann erneut hinzugefügt habe.

Irgendwie störend. Ich werde jetzt in Zukunft vermeiden, mich zu verstecken.

Die einzige Lösung besteht darin, ein neues Repository zu klonen und von vorne zu beginnen. (Beim letzten Mal gemacht)

Versuchen Sie es mit einem

Git Checkout -f

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

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

Ich lief git statusnach dem Löschen und die Änderungen waren weg. Sie kehrten nicht zurück, selbst nachdem .gitattributes wieder eingerichtet worden war.

Konsistente Zeilenenden sind eine gute Sache. Zum Beispiel wird es keine unnötigen Zusammenführungen auslösen, wenn auch trivial. Ich habe gesehen, wie Visual Studio Dateien mit gemischten Zeilenenden erstellt hat.

Auch einige Programme wie bash (unter Linux) erfordern, dass .sh-Dateien LF-terminiert sind.

Um dies sicherzustellen, können Sie gitattributes verwenden. Es funktioniert auf Repository-Ebene, unabhängig vom Wert von autcrlf.

Zum Beispiel können Sie .gitattributes wie folgt haben: * text = auto

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

Dann kann autocrlf Zeilenenden für Windows-Programme lokal konvertieren.

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

Ich hatte auch die gleichen Symptome, wurde aber durch verschiedene Dinge 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 wenn git rm --cached app.jses als gelöscht und in nicht verfolgten Dateien angezeigt wird, konnte ich app.js sehen. Aber als ich es erneut versuchte, rm -rf app.jszeigte git statuses mir immer noch die Datei in "untracked".

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

Da das Gruntaktiviert wurde und app.js aus einigen anderen js-Dateien generiert wurde, haben wir festgestellt, dass grunt nach jedem Vorgang mit js-Dateien (auch diese app.js) app.js erneut erstellt.

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

Beispiel für dieses Problem und wie man es überprüft:

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 git mit korrekt einrichten

git config --global core.filemode false

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 einer ...

Unser Problem war, dass wir keine Durchsetzung für Endlines hatten und das Repository eine Mischung aus DOS / Unix hatte. Schlimmer noch war, dass es sich in dieser Position tatsächlich um ein Open-Source-Repo handelte, das wir gegabelt hatten. Die Entscheidung wurde von denjenigen getroffen, die primär Eigentümer des Betriebssystem-Repositorys sind, alle Endlinien auf Unix zu ändern, und es wurde ein Commit getroffen, das eine .gitattributesDurchsetzung der Zeilenenden beinhaltete.

Leider schien dies zu Problemen zu führen, wie sie hier beschrieben wurden. Sobald eine Zusammenführung von Code vor DOS-2-Unix durchgeführt wurde, wurden die Dateien für immer als geändert markiert und konnten nicht zurückgesetzt werden.

Während meiner Recherche bin ich auf Folgendes gestoßen : https://help.github.com/articles/dealing-with-line-endings/ - Wenn ich erneut auf dieses Problem stoße, würde ich es zunächst ausprobieren.

Folgendes habe ich getan:

1. Ich hatte zunächst eine Zusammenführung durchgeführt, bevor mir klar wurde, dass ich dieses Problem hatte, und musste das abbrechen - git reset --hard HEAD( Ich bin auf einen Zusammenführungskonflikt gestoßen. Wie kann ich die Zusammenführung abbrechen? )

2. Ich habe die fraglichen Dateien in VIM geöffnet und zu Unix ( :set ff=unix) gewechselt . Ein Werkzeug wie dos2unixkönnte natürlich stattdessen verwendet werden

3. engagiert sein

4. hat das masterin zusammengeführt (der Master hat die DOS-2-Unix-Änderungen)

   git checkout old-code-branch; git merge master

5. Behobene Konflikte und die Dateien waren wieder DOS, mussten also :set ff=unixin VIM. (Hinweis: Ich habe https://github.com/itchyny/lightline.vim installiert, sodass ich sehen konnte, welches Dateiformat in der VIM-Statuszeile angezeigt wird.)

6. engagiert sein. Alles sortiert!

Das Problem, auf das ich gestoßen bin, ist, dass Windows sich nicht um die Großschreibung von Dateinamen kümmert, Git jedoch. Git hat also eine Klein- und Großbuchstabenversion der Datei gespeichert, konnte aber nur eine auschecken.

Ich habe alle Änderungen festgeschrieben und dann das Festschreiben ausgeführt und rückgängig gemacht. Das hat bei mir funktioniert

git hinzufügen.

git commit -m "Zufälliges Festschreiben"

git reset --hard HEAD ~ 1

Normalerweise sollten in GIT die folgenden 2 Befehle sehr gut funktionieren , um alle Ihre Änderungen und neuen Dateien zu löschen (seien Sie vorsichtig , dies löscht alle Ihre neuen Dateien + Ordner, die Sie möglicherweise erstellt haben, und stellt alle Ihre geänderten Dateien auf den aktuellen Stand zurück Commit ):

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

Vielleicht ist es manchmal eine bessere Option, "git stash push" mit einer optionalen Nachricht auszuführen, wie folgt:

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

Dadurch werden auch alle Ihre neuen und geänderten Dateien gelöscht, aber Sie haben alle gespeichert, falls Sie sie wiederherstellen möchten. Stash in GIT wird von Zweig zu Zweig übertragen, sodass Sie sie bei Bedarf in einem anderen Zweig wiederherstellen können.

Nebenbei bemerkt, falls Sie bereits einige neu hinzugefügte Dateien bereitgestellt haben und diese entfernen möchten, sollte dies den Trick tun:

$ git reset --hard

Wenn all das bei Ihnen nicht funktioniert , lesen Sie unten, was vor einiger Zeit bei mir funktioniert hat:

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 spezielle Git-Verhalten wurde heute dadurch verursacht, dass ich aus meinem "Entwicklungs" -Zweig einen neuen Zweig erstellt habe. Aus irgendeinem Grund blieben einige scheinbar zufällige Dateien bestehen, nachdem ich wieder zum Zweig "Entwickeln" gewechselt war, und wurden im "Git-Status" als "geändert" angezeigt.

Außerdem konnte ich zu diesem Zeitpunkt keinen anderen Zweig auschecken, sodass ich in meinem "Entwicklungs" -Zweig stecken blieb.

Das habe ich getan:

$ git log

Ich habe festgestellt, dass der neue Zweig, den ich heute aus "Entwickeln" erstellt habe, in der ersten "Festschreiben" -Nachricht angezeigt wird, auf die am Ende "KOPF -> Entwickeln, Ursprung / Entwickeln, Ursprung / KOPF, Der Zweig , den ich erstellt habe" verwiesen wird -früher-heute ".

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:

$ 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 werden versteckte Änderungen angezeigt, und da ich nur wenige hatte und keine meiner $ git stash clearVerstecke brauchte, habe ich ALLE STASHES GELÖSCHT.

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

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

Dies hat möglicherweise auch funktioniert. Ich werde es sicher versuchen, wenn ich das nächste Mal auf dieses Problem stoße.

Wenn Sie ein Repository klonen und ausstehende Änderungen sofort sehen, befindet sich das Repository in einem inkonsistenten Zustand. Bitte kommentieren Sie NICHT * text=autoaus der .gitattributesDatei. Dies wurde speziell dort platziert, weil der Eigentümer des Repositorys möchte, dass alle Dateien konsistent mit LF-Zeilenenden gespeichert werden.

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

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

Führen Sie dann die Filiale mit dem Eigentümer des Repos zusammen (oder ziehen Sie die Anforderung ab).

Nichts anderes auf dieser Seite hat funktioniert. Das hat endlich bei mir funktioniert. Es werden keine nicht verfolgten oder festgeschriebenen Dateien angezeigt.

git add -A
git reset --hard

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

git checkout <file>

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

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

git reset --hard
git pull origin
git merge

Ich habe es gelöst, indem ich .git / config bearbeitet und hinzugefügt habe:

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

Dann ging ich zu .git / refs / Heads / name_branch und platzierte die ID des letzten Commitsenter code here

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 zurücksetzen können), von Ihrer Festplatte. Jetzt sollten Sie beide Versionen derselben Datei finden, die als gelöscht markiert sind.
3. Übernehmen Sie das Löschen der Dateien.
4. Erstellen Sie die Datei erneut mit demselben Namen und fügen Sie den richtigen Code ein, den Sie in Schritt 1 kopiert haben
5. Übernehmen Sie die Erstellung der neuen Datei.

Das hat bei mir funktioniert.

Eine hier vorgeschlagene Lösung funktionierte nicht. Ich fand heraus, dass die Datei tatsächlich einen Link zu einigen Sonderzeichen enthält:

% 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