Ich denke, vielleicht ist Jubobs Kommentar richtig. Ist Ihre "Datei" ein Submodul?
Diese Zeile (commit oder verwerfen den nicht verfolgten oder geänderten Inhalt in Submodulen) sollte nicht für normale Dateien erscheinen.
Hier ist, was ich vom Git-Status bekomme:
%Vor%Sie werden nicht sehen (den nicht verfolgten oder geänderten Inhalt in Submodulen festschreiben oder verwerfen) und (geänderter Inhalt) nach meiner README.txt
Sie müssen also vielleicht tun, was git empfohlen hat, und an den Inhalten in Submodulen arbeiten.
Edit: Zuvor dachte ich das "git add". könnte das Problem lösen, aber jetzt denke ich, dass es nicht konnte.
Sie können Dateien auf drei Arten hinzufügen
git add filenamewithpath
git add .
gleichzeitig können Sie alle Dateien hinzufügen und Sie können die Commit-Nachricht mit diesem Befehl schreiben
git commit -a -m 'your commit message'
Ich hatte das gleiche Problem. Mein persönliches "aha" war, dass ich zuvor eine Tracking-.git-Repository-Datei zu einem Unterordner hinzugefügt hatte und diese somit als Submodul angesehen wurde. Nach dem Entfernen der .git-Datei im Unterordner ist sie glücklicherweise mit dem Rest meiner Ordner als Teil einer einzigen Git-Datei im Stammordner verbunden. Ich wusste nicht einmal von Submodulen, vielleicht hilft das auch jemandem.
hatte das gleiche Problem, keine Ahnung warum aber eine .h-Datei nicht committen würde.
Also habe ich es umbenannt, dieses Original gelöscht und neu erstellt, soweit es ein Git betrifft. Dann habe ich diese Änderungen vorgenommen. Git war glücklich.
Dann habe ich es gerade umbenannt. Wieder war git glücklich, sich zu verpflichten.
Kann nicht erklären, warum das passiert ist, aber zumindest wurde es behoben.
Nicht sicher, ob dies relevant ist oder nicht, aber ich hatte das gleiche Problem beim Wechsel zwischen Linux und Windows. Ich hatte 2 Dateien eine WEB.config und eine andere web.config, da Windows nicht Groß-und Kleinschreibung ist es scheint, verwirrt zu haben. Ich habe die umbenannte Datei umbenannt zurück umbenannt und scheint wieder funktioniert zu haben.
Es war gestern mit mir passiert, mein Freund, der Grund war, weil ich versucht habe, git aus einem Unterverzeichnis meines Projekts herauszurufen. Dann habe ich die " git add --all " verwendet und es löste das Problem, auch ich wäre in das richtige Verzeichnis darüber gegangen, das Problem würde auch gelöst.
Aber was ich nicht verstehe, war: Warum in der Welt funktionierte der git-Status und git --all-Befehl überhaupt aus einem Unterverzeichnis? .-.
Ich hoffe, es hilft =)
Dieses ähnliche Ding ist mir passiert. Egal was ich tat, die Datei erschien modifiziert. Bei der Betrachtung des Diff wurde es wie bei einem früheren Commit geändert. Die Datei schien immer verändert zu sein, auch nach dem ersten Mal. Endlich habe ich die Datei entfernt. Ich verpflichtete die Entfernung, die erschien, als hätte ich zwei Dateien entfernt. Dann fügte die Datei erneut hinzu. Ziemlich seltsame Sache, die ich noch nie zuvor gesehen habe.
Eine weitere Option ist, dass die gleiche Datei sich im Stash befindet und in Konflikt mit der aktuellen Kopie steht.
Wenn dies der Fall ist, wird git stash drop - den Stash löschen (mit der Datei im Konflikt) und Ihnen erlauben, die modifizierte Datei zum Index hinzuzufügen.
Das hat die Arbeit für mich getan. Staging aller Dateien, die bereit waren, die Datei (den geänderten Inhalt) zu übernehmen, enthalten
Sichern Sie die problematischen Dateien. Entferne diese Dateien, schreibe die Löschung, drücke einmal zum Ursprung.
Fügen Sie die Dateien aus dem Backup zurück und geben Sie ein neues Add, Commit und Push aus. Das Problem wird gelöst.