Warum erkennt git nicht, dass meine Datei geändert wurde, daher funktioniert git add nicht

Ich hatte ein Problem, als ich einmal den Git-Index auf "unverändert" gesetzt habe.

Sie können git anweisen, Änderungen an der Datei nicht mehr zu ignorieren:

git update-index --no-assume-unchanged path/to/file

Wenn dies nicht hilft, kann ein reset für andere komische Fälle ausreichen. 

In der Praxis fand ich heraus, dass ich die zwischengespeicherte Datei entfernte und wieder funktioniere:

git rm --cached path/to/file
git reset path/to/file

git rm --cached bedeutet, die Datei nur aus dem Index zu entfernen, und reset weist git an, den git-Index vom letzten Commit neu zu laden.

Ein weiterer möglicher Grund (der sich in meinem aktuellen Fall als richtig herausstellte). Überprüfen Sie Ihre .gitignore-Datei. Möglicherweise stellen Sie fest, dass die Datei oder Erweiterung der Datei, mit der Sie arbeiten möchten, in .gitignore eingetragen ist. Dies würde erklären, warum sie nicht als geänderte Datei erkannt wird.

nun, wir haben nicht genug, um diese Frage zu beantworten, also werde ich Ihnen einige Vermutungen geben:

1) Sie haben Ihre Änderungen gespeichert, um den Typ zu ändern: git stash pop

2) Sie hatten Änderungen und Sie haben sie festgelegt, Sie sollten Ihr Commit in git log sehen können.

3) Sie hatten Änderungen an git reset --hard oder anderen vorgenommen, Ihre Änderungen können im Reflog enthalten sein. Geben Sie git reflog --all ein, gefolgt von einem Check-Out oder einem Kirschpicking, wenn Sie es jemals finden.

4) Sie haben das gleiche Repo mehrmals ausgecheckt und befinden sich im falschen.

Hatte so etwas funky passiert. Das git plugin von Eclipse Kepler markierte automatisch alle meine Projektordner als ignoriert im .gitignore-Ordner.

Wenn ich im Menü commit auf Team zugreifen würde, würden sie alle wieder ignoriert werden. Soweit ich das beurteilen kann, lag das daran, dass ich sie im übergeordneten Projekt als abgeleitete festgelegt hatte. Das Aufheben der Markierung als dervied hat dieses Problem behoben. Ich hatte das noch nie auf Indigo gesehen. Hoffe, es hilft jemandem.

Ich hatte ein ähnliches Problem bei der Verwendung von Sublime Text-3 . Nachdem ich neue Änderungen am Code vorgenommen und gespeichert hatte, als ich die Befehle git add ./status ausprobierte, lautete die Antwort "Verzweigung bereits auf dem neuesten Stand" Editor war die Datei eigentlich unverändert. Öffnen der Datei in einem anderen Editor und Speichern der für mich vorgenommenen Änderungen.

Dies ist unter Windows beim Ändern von Dateien durch die Übertragung von Unterschieden mit dem WinMerge-Tool aufgetreten. Anscheinend aktualisiert WinMerge (zumindest die Art, wie es auf meinem Computer konfiguriert ist) die Zeitstempel der Dateien, die es ändert, manchmal nicht.

Unter Windows verwendet git status unter anderem den Zeitstempel einer Datei und Änderungen in der Dateigröße, um festzustellen, ob sich eine Datei geändert hat oder nicht. Da der Zeitstempel nicht aktualisiert wurde, hatte er nur die Dateigröße. Leider handelt es sich bei der betreffenden Datei um eine einfache Versionsdatei, bei der der Inhalt von 7.1.2 in 7.2.0 geändert wurde. Mit anderen Worten blieb auch die Dateigröße unverändert. Bei anderen Dateien, die ebenfalls von WinMerge geändert wurden und deren Zeitstempel nicht aktualisiert wurden, hatten sie jedoch nach der Änderung eine andere Größe, als git status just fine.

Wenn Sie eine Datei in Visual Studio bearbeiten, wird sie sofort in git changes aufgelistet, auch wenn die Datei nicht gespeichert ist. Sie müssen die Datei also nur manuell speichern (Strg + S für die aktuell angezeigte Datei oder Strg + Shift + S für alle Projektdateien), und git bash übernimmt sie.

Klingt verrückt, aber manchmal bist du nicht im richtigen Repo, auch wenn du denkst, dass du es bist. Sie haben beispielsweise das übergeordnete Verzeichnis verschoben, aber vergessen, die Repos in Ihrem Texteditor zu ändern. Oder umgekehrt: Sie befinden sich im richtigen Repo im Texteditor, aber das falsche Repo in der Befehlszeile. In der ersten Situation nehmen Sie Ihre Änderungen in der rechten Datei vor , aber es ist nicht derselbe Ordner, der in Ihrer Befehlszeile geöffnet ist. Es handelt sich also tatsächlich um die falsche Datei. In der zweiten Situation haben Sie tatsächlich die richtige Datei bearbeitet, aber Ihr Befehlszeilengit erkennt die Änderung nicht, da Sie sich nicht im richtigen Verzeichnis in der Befehlszeile befinden.

TL; DR; Sind Sie überhaupt im richtigen Repository?

Meine Geschichte ist ein bisschen witzig, aber ich dachte, es könnte mit jemandem passieren, der ein ähnliches Szenario hat, also hier teilen.

Auf meinem Rechner hatte ich eigentlich zwei separate Git-Repositorys repo1 und repo2, die in demselben Stammverzeichnis mit dem Namen source konfiguriert waren. Diese beiden Repositories sind im Wesentlichen die Repositories zweier Produkte, an denen ich in meinem Unternehmen arbeite. Die Sache ist nun, dass die Verzeichnisstruktur des Quellcodes aller Produkte als Standardrichtlinie in meinem Unternehmen genau gleich ist. 

Ohne es zu merken, änderte ich eine exakt gleichnamige Datei in repo2, die ich in repo1 ändern sollte. Also habe ich einfach den Befehl git status für repo1 ausgeführt und es gab immer die gleiche Nachricht 

Auf dem Zweigmeister

nichts zu begehen, Arbeitsverzeichnis sauber

für eine halbe Stunde. Dann bemerkte mein Kollege es als unabhängiges Augenpaar und stellte dieses Ding fest, dass ich mich in einem falschen, aber sehr ähnlich aussehenden Repository befand. In dem Moment, als ich zu repo1 Git wechselte, bemerkte ich die geänderten Dateien.

Nicht so häufig. Aber du weißt nie!

Ich hatte dieses Problem. Meine hat nicht funktioniert, weil ich meine Dateien im .git-Ordner in meinem Projekt abgelegt habe.

Wie bereits erwähnt, wurden die Dateien wahrscheinlich mit "assume-unverändert" gekennzeichnet, was git im Grunde sagt, dass Sie die Dateien nicht ändern werden, so dass Änderungen nicht mit ihnen nachverfolgt werden müssen. Dies kann sich jedoch auf mehrere Dateien auswirken, und wenn es sich um einen großen Arbeitsbereich handelt, möchten Sie möglicherweise nicht alle nacheinander überprüfen. In diesem Fall können Sie versuchen: git update-index --really-refresh

laut den docs:

Like --refresh, but checks stat information unconditionally, without regard to the "assume unchanged" setting.

Es wird git grundsätzlich zwingen, Änderungen aller Dateien zu verfolgen, unabhängig von den "unveränderten" Flags.

Vergewissern Sie sich im Allgemeinen bei diesem Problem, dass Sie die Datei bearbeiten, von der Sie glauben, dass Sie sie sind! Ich hatte dieses Problem, als ich eine transpilierte JavaScript-Datei anstelle der Quelldatei editierte (die transpiled-Version stand nicht unter Quellcodeverwaltung).

Manchmal hängen und von git Version ab und wenn Sie vergessen, git add . zu tun.

Verwenden Sie immer git status, um alle Änderungen an dem Repository anzuzeigen, die alle nicht protokollierten und geänderten Dateien anzeigen. Weil git diff nur hinzugefügte Dateien anzeigt.

Mein Git-Client (Gitg) hat dieses Problem für mich verursacht. Normale Befehle, die ich normalerweise ausführen würde, funktionierten nicht. Selbst das Berühren aller Dateien im Projekt funktionierte nicht.

Ich habe einen Weg gefunden, das Problem zu beheben, und ich bin mir immer noch nicht sicher, was es verursacht hat. Kopieren Sie Ihr Projektverzeichnis. Die fehlenden Dateien werden im git status des kopierten Verzeichnisses angezeigt. Das Umbenennen macht vielleicht dasselbe.

Stellen Sie sicher, dass nicht , um Symlinks (ln -s source dest) innerhalb von Git Bash für Windows zu erstellen.

Es erstellt KEINE Symlinks, sondern eine DEEP-Kopie der Quelle zum Ziel

Ich habe dasselbe Verhalten wie OP auf einem MINGW64-Terminal von Git Bash für Windows (Version 2.16.2) erlebt, als mir klar wurde, dass sich die "bearbeiteten" Änderungen tatsächlich im ursprünglichen Verzeichnis befanden und meine Git-bash-Befehle aus einer tiefen Kopie stammen, die noch vorhanden war unverändert.

Ich hatte das gleiche Problem. Es stellte sich heraus, dass ich zwei Kopien des Projekts hatte und mein Terminal sich im falschen Projektordner befand!

Stieß auf das Problem, aber es waren nur zwei Verzeichnisse, und mir war nicht bekannt, dass beide Verzeichnisse als Git-Submodule konfiguriert wurden. Wie das passiert ist, habe ich keine Ahnung, aber der Prozess war, einige der Anweisungen auf diesem Link zu befolgen, aber NICHT das Verzeichnis zu entfernen (wie er es am Ende tut), sondern git add path/to/dir

Welche Art von Datei haben Sie versucht, hochzuladen? Jetzt verbringe ich fast eine Stunde, um meine CSS-Modifikation hochzuladen. Diese aus einer styl-Datei zusammengestellte CSS wurde von git daher einfach ignoriert. Als ich die Stilquelle änderte, funktionierte alles.

Ich hoffe es hilft.

Haben Sie das Verzeichnis unter Ihrer Shell herausgezogen? Dies kann passieren, wenn Sie Ihr Projekt aus einer Sicherung wiederherstellen. Um dies zu beheben, einfach cd raus und wieder rein:

cd ../
cd -