.gitignore ignoriert Dateien nicht oder ignoriert Dateien die nicht ignoriert werden sollen

[ebody]

Hallo,

die .gitignore ignoriert Dateien nicht oder ignoriert Dateien die nicht ignoriert werden sollen. Um das zu prüfen verwende ich git status --ignored.

Ich hatte so ein Problem schon einmal, da war der Grund, dass die Datei UTF-8 nicht kodiert war. Das ist es diesmal nicht.

Die .gitignore wurde mit dem Befehl npx create-react-app... erzeugt, neben anderen Dateien. Die Dateien und Ordner die darin schon angegeben sind, werden ignoriert:

# dependencies
/node_modules
/.pnp
.pnp.js

# testing
/coverage

# production
/build

Meine ergänzten Dateien und Ordner nicht.

package-lock.json
package.json
/sonstiges
/templates
src/App.test.js
src/reportWebVitals.js
src/setupTest.js

Eigentlich kenne ich es so, dass bei Verzeichnissen der / ans Ende kommt: templates/. Habe ich auch probiert, funktioniert aber auch nicht.

Wenn ich mit git add . Dateien an den Index sende und mit git status -s anzeige, welche Dateien jetzt im Index liegen, fehlen einige Dateien. Diese sind aber gar nicht in der .gitignore.

Hat jemand eine Idee, woran das alles liegen könnte?

Gruß ebody

[dedlfix]

Tach!

Ich hatte so ein Problem schon einmal, da war der Grund, dass die Datei UTF-8 nicht kodiert war. Das ist es diesmal nicht.

Solange keine Nicht-ASCII-Zeichen (zum Beispiel Umlaute) darin vorkommen, ist es egal. Es gibt dann keinen Unterschied zwischen ASCII, ISO-8859-1 und UTF-8.

package-lock.json
package.json
/sonstiges
/templates
src/App.test.js
src/reportWebVitals.js
src/setupTest.js

Wann hast du denn diese Einträge zur .gitignore hinzugefügt? Waren diese Dateien zu dem Zeitpunkt bereits Bestandteil des Repositorys? Sie werden dann nicht mehr ignoriert. Du musst sie erst mit git rm aus dem Repository entfernen, damit sie für neue git add ignoriert werden.

Warum möchtest du die package.json ausschließen? Darin stehen die für dein Projekt notwendigen Abhängigkeiten drin.

Eigentlich kenne ich es so, dass bei Verzeichnissen der / ans Ende kommt: templates/.

Kann man machen, dann ist es eindeutig ein Verzeichnis. Ohne / trifft es Dateien und Verzeichinsse gleichermaßen, die so heißen.

Wenn ich mit git add . Dateien an den Index sende und mit git status -s anzeige, welche Dateien jetzt im Index liegen, fehlen einige Dateien. Diese sind aber gar nicht in der .gitignore.

Sind diese Dateien denn geändert wurden?

Und warum tust du es dir an, git per Kommandozeile zu steuern? Es gibt GUI-Programme für git, mit denen sieht man übersichtlicher, was los ist, ohne die Informationen einzeln per Befehl abzufragen.

dedlfix.

[ebody]

Hallo,

Solange keine Nicht-ASCII-Zeichen (zum Beispiel Umlaute) darin vorkommen, ist es egal. Es gibt dann keinen Unterschied zwischen ASCII, ISO-8859-1 und UTF-8.

Ah ok 👍

Wann hast du denn diese Einträge zur .gitignore hinzugefügt? Waren diese Dateien zu dem Zeitpunkt bereits Bestandteil des Repositorys? Sie werden dann nicht mehr ignoriert. Du musst sie erst mit git rm aus dem Repository entfernen, damit sie für neue git add ignoriert werden.

Dateien später in .gitignore zugefügt und waren im ersten Commit enthalten, also Bestandteil des Repositorys. Kann man mit git ls-tree <id> -r sehen.

Löscht man mit git rm nicht Dateien aus dem Workspace (1) und Index (2) und mit git rm --cached nur aus dem Index (2), aber nicht aus dem Repository (3)?

Ich habe daher jetzt git reset --mixed HEAD~1 verwendet, um Commits zu entfernen und den Index auf den gleichen Stand (Snapshot) zu bringen. Aber den ersten und jetzt noch einzigen Commit kann ich nicht löschen.

Warum möchtest du die package.json ausschließen? Darin stehen die für dein Projekt notwendigen Abhängigkeiten drin.

Bisher benötige ich Datei nicht und muss auch erstmal schauen, wofür sie genau ist. Da ich das Repository auch auf github veröffentlichen möchte, möchte ich erstmal nur Dateien da stehen haben, die ich aktuell brauche.

Sind diese Dateien denn geändert wurden?

Nein. Verstehe jetzt glaube ich aber... Dann hat sich deren Status auch nicht geändert und werden mit git status -s nicht aufgelistet. Diese Dateien befinden sich bereits im ersten Commit (Snapshot), wurden im Workspace nicht geändert und brauchen/werden daher nicht an den Index gesendet.

Und warum tust du es dir an, git per Kommandozeile zu steuern? Es gibt GUI-Programme für git, mit denen sieht man übersichtlicher, was los ist, ohne die Informationen einzeln per Befehl abzufragen.

Ich möchte die Befehle erstmal lernen und verstehen.

Gruß ebody

[dedlfix]

Tach!

Löscht man mit git rm nicht Dateien aus dem Workspace (1) und Index (2) und mit git rm --cached nur aus dem Index (2), aber nicht aus dem Repository (3)?

Ich kenne die Befehle und deren Parameter nicht, kann gut sein, dass ich da was falsches gesagt habe. Aber ich hoffe, es ist trotzdem klar geworden, was ich gemeint habe.

Warum möchtest du die package.json ausschließen? Darin stehen die für dein Projekt notwendigen Abhängigkeiten drin.

Bisher benötige ich Datei nicht und muss auch erstmal schauen, wofür sie genau ist. Da ich das Repository auch auf github veröffentlichen möchte, möchte ich erstmal nur Dateien da stehen haben, die ich aktuell brauche.

Du hast doch eine React Anwendung erstellt, und dabei auch ein npm i(nstall) und npm run build ausgeführt. Damit hast du die package.json indirekt verwendet. Selbst wenn du ihre Verwendungsmöglichkeiten noch nicht erkannt hast, der npm benötigt sie zwingend.

Und warum tust du es dir an, git per Kommandozeile zu steuern? Es gibt GUI-Programme für git, mit denen sieht man übersichtlicher, was los ist, ohne die Informationen einzeln per Befehl abzufragen.

Ich möchte die Befehle erstmal lernen und verstehen.

Man muss die Arbeitsweise verstehen, dazu muss man nicht zwangsläufig die nackten Befehle kennen. Mann braucht vielleicht gelegentlich den einen oder anderen Befehl, wenn man auf einem Server ein Repository clonen oder einen Stand auschecken möchte. Aber die meiste Zeit arbeitet man doch auf der Entwicklungsmaschine, und da hat eine GUI wesentlich bessere Möglichkeiten, etwas zu präsentieren und zu steuern, als git im Terminal mit Texausgabe und getippten Befehlen. Aber gut, wenn du meinst, das CLI nützt dir mehr, dann sei es so.

dedlfix.

[Der Martin]

Hallo,

ganz unabhängig von der Anwendung oder dem Tool, um das es geht:

Ich möchte die Befehle erstmal lernen und verstehen.

Man muss die Arbeitsweise verstehen, dazu muss man nicht zwangsläufig die nackten Befehle kennen.

Absolut d'accord. Das ist wie in der Schule: Formeln auswendig lernen und bei der Klausur stur wieder abspulen kann helfen, irgendwann durch die Prüfung zu kommen. Besser ist aber, den Sinn und Hintergrund dessen zu verstehen, wofür die Formel gedacht ist. Dann kann man nämlich auch andere, ähnlich gelagerte Probleme lösen, ohne zu resignieren, "weil das in den Beispielen nicht vorkam".

[...] und da hat eine GUI wesentlich bessere Möglichkeiten, etwas zu präsentieren und zu steuern, als git im Terminal mit Texausgabe und getippten Befehlen. Aber gut, wenn du meinst, das CLI nützt dir mehr, dann sei es so.

Es gibt gute und weniger gute, teils auch richtig miserable GUI-Lösungen. Tendentiell sind mir kommandozeilenbasierte Ansätze aber auch lieber. Ich finde eine Eingabezeile, auch wenn sie eine Handvoll Parameter und Schalter enthält, die man halt im Kopf haben muss, dennoch angenehmer als sich durch ein Dutzend Menüs und Dialogfenster zu klicken.

Ganz zu schweigen davon, dass man auf diese Weise rechenintensive und/oder zeitraubende Operationen als Batch zusammenfassen und dann sagen kann, "Mach mal". Wenn man dann vom Spaziergang oder vom Einkaufen zurück ist, ist sie^[1] fertig. Das ist bei GUI-Lösungen meist nicht möglich, weil ich einen Vorgang nach dem anderen manuell anstoßen muss.

Möge der Kaffee gut und der Montag kurz sein
 Martin

---

1. Ihr wisst schon, Computer sind grundsätzlich weiblich: Schwer zu durchschauen, eigensinnig, manchmal auch ein bisschen zickig - aber man mag doch nicht auf sie verzichten. ↩︎

[ebody]

Ich kenne die Befehle und deren Parameter nicht, kann gut sein, dass ich da was falsches gesagt habe. Aber ich hoffe, es ist trotzdem klar geworden, was ich gemeint habe.

Ja ist es und der Hinweis war auch hilfreich👍 Dennoch wollte ich fragen und darauf hinweisen, da später evtl. auch andere die Beiträge mal lesen. Deswegen noch ein paar Hinweise, auch zu dem ganzen Problem was ich hatte:

Entscheidend waren nicht die Commits, sondern was aktuell im Index liegt. Das sieht man mit git ls-files. Liegen im Index schon die Dateien, die ich ignorieren möchte, kann Git diese nicht mehr ignorieren. Daher müssen sie aus dem Index gelöscht werden mit

# Löscht alle Dateien aus dem Index
git rm -r --cached . 

# Löscht file.js aus dem Index
git rm -r --cached file.js

# Löscht file.js und app.js aus dem Index
git rm -r --cached file.js app.js

Ich habe daher jetzt git reset --mixed HEAD~1 verwendet, um Commits zu entfernen und den Index auf den gleichen Stand (Snapshot) zu bringen. Aber den ersten und jetzt noch einzigen Commit kann ich nicht löschen.

Würde hier nicht helfen. Denn reset setzt nur den HEAD Pointer auf den Commit der zuvor gemacht wurde und passt den Index (Staging Area) an diesen Commit an. Im Index würden also weiterhin die Dateien liegen, die ich ignorieren möchte da der Commit zuvor diese Dateien auch schon enthielt.

Quelle: Mosh - Git Tutorial for Beginners

git reset --mixed HEAD~1 wäre nützlich, wenn man vermeiden möchte, dass die Dateien, die man ignorieren möchte in den bereits getätigten Commits gefunden werden können. Weil man z.B. sensible Informationen wie einen API Key darin stehen hatte. Aber das Problem was ich hier hatte, ich konnte den noch einzig übrigen Commit nicht löschen, der die Dateien enthielt.

Gruß ebody