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

222

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")
Rbellamie
quelle
6
Ich bin mir nicht sicher, warum das git reset --hardhier nicht funktioniert hat. Hinweis: Es sollte sein git checkout -- `git ls-files -m`, die Dateien abzubrechen ( --)
VonC
2
Wenn Sie die Dateien löschen und verwenden checkout -- <file>, sollte es funktionieren. Die Änderungserkennung ist in einigen Situationen etwas wählerisch (unter anderem, wenn eine CRLF-
Nichtübereinstimmung
Mögliches Duplikat von Kann Änderungen in Git
BuZZ-dEE
1
@ BuZZ-dEE - es ist ein Duplikat und älter und würde daher Vorrang haben. Obwohl die Frage, auf die Sie verlinken, im Wesentlichen dieselbe ist, ist die Antwort, die ich unten akzeptiert habe, viel informativer als jede der dortigen Antworten und hat mein Problem gelöst.
Rbellamy
keine lösung, sondern ein schweizer messer für langweilige git update-index --assume-unchagedfall : erzwingt den unveränderten zustand der dateien (auch für die geänderten!)
pdem

Antworten:

126

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.

Ikke
quelle
8
Okay ... also das hat es geschafft ... jetzt zeigt der Git-Status keine Änderungen an. Ich habe die Autocrlf-Einstellungen nachgelesen und kann es einfach nicht richtig machen.
Rbellamy
1
Guter Fang! +1. Ein weiteres Argument für mich, das auf false zu setzen ( stackoverflow.com/questions/1249932/… ).
VonC
Was bedeutet das: "Eine Datei, die vor dem Festschreiben eine Mischung aus LF und CRLF enthält, kann von git nicht neu erstellt werden." Liegt das daran, dass git die Zeilenenden basierend auf der Einstellung core.autocrlf immer normalisiert?
Rbellamy
1
Eine vernünftigere Lösung für das Problem der Groß- und Kleinschreibung besteht darin, nicht mehrere Ordner in Ihrem Repo zu haben, deren Namen sich nur von Fall zu Fall unterscheiden .
Ohad Schneider
3
Um Namen von Dateien zu finden, die sich nur durch die Groß- und Kleinschreibung unterscheiden, können Sie ausführen git ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d. Um sowohl Groß- als auch Kleinbuchstaben solcher Dateien git 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
aufzulisten,
220

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

Rian Sanderson
quelle
8
Ein weiterer Erfolg hier nach dem Wechsel core.autocrlfhatte keine Auswirkungen.
Daniel Buckmaster
8
Hatte dieses Problem unter Windows sogar mit core.autocrlf false. Diese Antwort funktionierte, wenn nichts anderes würde.
Kenchilada
9
Ich habe mehrere Vorschläge aus dieser und anderen Fragen ausprobiert. Dies ist die einzige Lösung, die bei mir funktioniert hat. Ich hatte keine Attributdatei und habe bereits mit core.autocrlf bei false begonnen.
BrotherOdin
4
Das hat bei mir nicht funktioniert. Also habe ich es hässlicher gemacht, indem ich eine neue Niederlassung gegründet habe, um diese Änderungen zu übernehmen, da sie für mich sowieso nutzlos sind. [java] git checkout -b a-branch-to-commit-bad-crlf-dateien [/ java] [java] git commit -am "die schlechten crlf-dateien festschreiben" [/ java]
Mohd Farid
3
Manchmal lassen mich solche Probleme SVN wirklich vermissen.
Mike Godin
104

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.
zebediah49
quelle
1
Ich war in den letzten Stunden nicht in der Lage, Dateien zurückzusetzen, abzurufen oder zu speichern. DAS war die Lösung für mich! Vielen Dank! (Git 1.8.3.1)
NuSkooler
3
Ich habe viele Dinge ausprobiert, bevor ich damit endlich Erfolg hatte. Danke dir!
Ghenghy
1
Wie funktioniert das? Ich würde denken, dass die .gitattributesRü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.
JDK1.0
1
@ jdk1.0 Mein Verständnis / meine Vermutung ist, dass zwei verschiedene Vergleichsmethoden beteiligt sind. Der Fehler tritt auf, wenn irgendwo eine andere Zeile endet und Git sie manchmal ignoriert. Wenn Sie fragen git status, stellt es fest, dass es sich um verschiedene Dateien handelt. Wenn Sie fragen git 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 ist HEAD. Sobald dies behoben ist, ist es in Ordnung, die Wiederaufnahme der Klugheit zuzulassen, da keine neuen Fehler hinzugefügt werden.
Zebediah49
3
Habe ein paar Stunden damit verbracht und diese Lösung hat endlich für mich funktioniert!
Maryam
71

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

Marty Neal
quelle
3
Danach müssen Sie möglicherweise einengit checkout .
Marty Neal
2
Arbeitete für mich, ohne erneut
auschecken
3
Zum späteren Nachschlagen: Um zu wissen, ob dies der Fix ist, den Sie benötigen (und nicht die anderen Fixes in anderen Antworten), verwenden Sie git diffund es werden Dateien mit solchen Modusänderungen angezeigt old mode 100755 / new mode 100644.
pgr
Dies hat es für mich behoben, nachdem absolut nichts anderes würde. Ich denke wirklich nicht, dass Leute Git-Cheatsheets und "einfache Anleitungen" im Internet machen sollten. Git ist wirklich nicht nur zum Aufnehmen und Verwenden gedacht. Ich denke, es ist etwas, das Sie speziell und formell trainieren und üben müssen, bevor Sie es verwenden.
Danke, du hast mir viele Tränen erspart!
Lukasz
33

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
Richard Lalancette
quelle
Es kann hilfreich sein, den Inhalt der kommentierten Zeile zu erwähnen.
Rbellamy
Leider haben die meisten Projekte nicht diese optionale .gitattribute-Datei
mchiasson
Danke dir. Ich verstehe nur nicht, warum dies notwendig ist
Diogovk
Warum? Grundsätzlich ist dies eine vorübergehende Korrektur des Zeilenendes. Verwenden Sie die permanente Lösung, indem Sie dem Link im Hinweis folgen.
Richard Lalancette
11

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
moo moo
quelle
Das hat bei mir funktioniert. Beachten Sie, dass das --keep-indexwichtig ist.
user991710
Warum ist der --keep-Index wichtig?
Choylton B. Higginbottom
8

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)

Fam verkabelt
quelle
6

Versuchen Sie es mit einem

Git Checkout -f

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

nsg
quelle
Nett! Das hat bei mir funktioniert. Obwohl ich für einen hartnäckigen Fall zuerst git checkout -f <another recent branch>mitgit checkout -f <branch I'm working on>
Reversed Engineer
4

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.

Artfunkel
quelle
Dies funktioniert auch mit komplizierteren Gitattributen, z. B. Filtern
Samizdis
2

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.

dpiskyulev
quelle
2

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.

Nedvajz
quelle
2

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
bg17aw
quelle
2

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!
HankCa
quelle
2

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.

xaav
quelle
2

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

gcs06
quelle
2

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.

Derek Gogol
quelle
1

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

w25r
quelle
1

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
Philip Rego
quelle
1

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.

Jesper Lundin
quelle
0

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
b Seite
quelle
0

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

Victor Villacorta
quelle
0

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.

Michael Yousrie
quelle
0

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
Janus Troelsen
quelle