Ich möchte alle Änderungen an meiner Arbeitskopie entfernen.
Beim Ausführen git status
werden 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")
git
revert
git-status
working-copy
Rbellamie
quelle
quelle
git reset --hard
hier nicht funktioniert hat. Hinweis: Es sollte seingit checkout -- `git ls-files -m`
, die Dateien abzubrechen (--
)checkout -- <file>
, sollte es funktionieren. Die Änderungserkennung ist in einigen Situationen etwas wählerisch (unter anderem, wenn eine CRLF-git update-index --assume-unchaged
fall : erzwingt den unveränderten zustand der dateien (auch für die geänderten!)Antworten:
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:
Anstelle von core.autocrlf können Sie auch
.gitattribute
Dateien 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 :
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.
quelle
git ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d
. Um sowohl Groß- als auch Kleinbuchstaben solcher Dateiengit 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
Ich hatte dieses Problem unter Windows, war aber nicht bereit, die Auswirkungen der Verwendung zu untersuchen.
config --global core.autocrlf false
Ich 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:
(Beachten Sie, dass das Ausführen
git reset --hard
nicht gut genug warrm
und die Dateien vor dem,reset
wie in den Kommentaren zur ursprünglichen Frage vorgeschlagen, nicht eindeutig waren. )quelle
core.autocrlf
hatte keine Auswirkungen.core.autocrlf false
. Diese Antwort funktionierte, wenn nichts anderes würde.Eine andere Lösung, die für Menschen funktionieren kann, da keine der Textoptionen für mich funktioniert hat:
.gitattributes
durch eine einzelne Zeile :* binary
. Dies weist git an, jede Datei als Binärdatei zu behandeln, mit der es nichts anfangen kann.git checkout -- <files>
sie in der Repository-Version wiederherstellengit checkout -- .gitattributes
um die.gitattributes
Datei in ihren Ausgangszustand zurückzusetzenquelle
.gitattributes
Rückkehr zum Original das gleiche Problem wieder einführen würde, aber leider ist mein Problem jetzt gelöst. Keiner der anderen Vorschläge hat in meinem Fall funktioniert.git status
, stellt es fest, dass es sich um verschiedene Dateien handelt. Wenn Sie fragengit checkout
, stellt es fest, dass sie den gleichen Inhalt haben. Diese Lösung weist git vorübergehend an, mögliche Klugheiten am Zeilenende zu ignorieren und sicherzustellen, dass Ihre lokale Kopie Byte für Byte mit der von identisch istHEAD
. Sobald dies behoben ist, ist es in Ordnung, die Wiederaufnahme der Klugheit zuzulassen, da keine neuen Fehler hinzugefügt werden.Für zukünftige Menschen mit diesem Problem: Änderungen im Dateimodus können dieselben Symptome haben.
git config core.filemode false
wird es beheben.quelle
git checkout .
git diff
und es werden Dateien mit solchen Modusänderungen angezeigtold mode 100755 / new mode 100644
.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.
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:
quelle
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:
Und dann, um den Stash zu löschen:
quelle
--keep-index
wichtig ist.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
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)
quelle
Versuchen Sie es mit einem
Damit sollten alle Änderungen im aktuell funktionierenden lokalen Repo gelöscht werden
quelle
git checkout -f <another recent branch>
mitgit checkout -f <branch I'm working on>
Ich konnte dies nur beheben, indem ich die .gitattributes-Datei meines Repos (die definiert
* text=auto
und*.c text
) vorübergehend löschte .Ich lief
git status
nach dem Löschen und die Änderungen waren weg. Sie kehrten nicht zurück, selbst nachdem .gitattributes wieder eingerichtet worden war.quelle
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.
quelle
Ich hatte auch die gleichen Symptome, wurde aber durch verschiedene Dinge verursacht.
Ich war nicht in der Lage zu:
Selbst wenn
git rm --cached app.js
es als gelöscht und in nicht verfolgten Dateien angezeigt wird, konnte ich app.js sehen. Aber als ich es erneut versuchte,rm -rf app.js
zeigtegit status
es mir immer noch die Datei in "untracked".Nach ein paar Versuchen mit Kollegen haben wir herausgefunden, dass es von Grunt verursacht wurde!
Da das
Grunt
aktiviert 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.quelle
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:
Um dies zu vermeiden, sollten Sie sicherstellen, dass Sie git mit korrekt einrichten
quelle
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
.gitattributes
Durchsetzung 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:
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? )Ich habe die fraglichen Dateien in VIM geöffnet und zu Unix (
:set ff=unix
) gewechselt . Ein Werkzeug wiedos2unix
könnte natürlich stattdessen verwendet werdenengagiert sein
hat das
master
in zusammengeführt (der Master hat die DOS-2-Unix-Änderungen)git checkout old-code-branch; git merge master
Behobene Konflikte und die Dateien waren wieder DOS, mussten also
:set ff=unix
in VIM. (Hinweis: Ich habe https://github.com/itchyny/lightline.vim installiert, sodass ich sehen konnte, welches Dateiformat in der VIM-Statuszeile angezeigt wird.)quelle
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.
quelle
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
quelle
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 ):
Vielleicht ist es manchmal eine bessere Option, "git stash push" mit einer optionalen Nachricht auszuführen, wie folgt:
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:
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:
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:
Die geänderten Dateien wurden immer noch angezeigt, also habe ich:
Dies löste mein Problem:
Natürlich
$ git stash list
werden versteckte Änderungen angezeigt, und da ich nur wenige hatte und keine meiner$ git stash clear
Verstecke brauchte, habe ich ALLE STASHES GELÖSCHT.HINWEIS : Ich habe nicht versucht, das zu tun, was hier jemand vor mir vorgeschlagen hat:
Dies hat möglicherweise auch funktioniert. Ich werde es sicher versuchen, wenn ich das nächste Mal auf dieses Problem stoße.
quelle
Wenn Sie ein Repository klonen und ausstehende Änderungen sofort sehen, befindet sich das Repository in einem inkonsistenten Zustand. Bitte kommentieren Sie NICHT
* text=auto
aus der.gitattributes
Datei. 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:
Führen Sie dann die Filiale mit dem Eigentümer des Repos zusammen (oder ziehen Sie die Anforderung ab).
quelle
Nichts anderes auf dieser Seite hat funktioniert. Das hat endlich bei mir funktioniert. Es werden keine nicht verfolgten oder festgeschriebenen Dateien angezeigt.
quelle
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.
quelle
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):
quelle
Ich habe es gelöst, indem ich .git / config bearbeitet und hinzugefügt habe:
Dann ging ich zu .git / refs / Heads / name_branch und platzierte die ID des letzten Commits
enter code here
quelle
Ich habe es so gelöst:
Das hat bei mir funktioniert.
quelle
Eine hier vorgeschlagene Lösung funktionierte nicht. Ich fand heraus, dass die Datei tatsächlich einen Link zu einigen Sonderzeichen enthält:
quelle