git add * (Sternchen) vs git add. (Zeitraum)


129

Ich bin neu in Git und habe eine Frage zum Hinzufügen von Dateien in Git. Ich habe mehrere Fragen Stackoverflow über den Unterschied zwischen gefunden git add .und git add -a, git add --all, git add -Aetc. Aber ich habe es nicht gelungen , einen Platz zu finden, der erklärt , was der git add *Fall ist. Ich habe mir sogar die git add manpage angesehen , aber es hat nicht geholfen. Ich habe es anstelle von verwendet git add .und mein Kollege fragte mich warum. Ich hatte keine Antwort. Ich habe es einfach immer benutzt git add *.

Sind git add .und git add *das gleiche? Fügt einer nur geänderte Dateien aus dem aktuellen Verzeichnis hinzu, während der andere Dateien aus dem aktuellen Verzeichnis und den Unterverzeichnissen hinzufügt (rekursiv)?

Auf einer der anderen Stapelfragen ist ein großartiges Diagramm aufgeführt, das den Unterschied zwischen git add -A git add .und zeigt git add -u, aber nicht git add *.

Geben Sie hier die Bildbeschreibung ein

Hinweis: Ich verstehe, was es bedeutet, das Sternchen als Platzhalter zu verwenden (alle Dateien mit einer bestimmten Erweiterung hinzufügen). Zum Beispiel git add *.htmlwürde alle Dateien hinzufügen , die eine haben .htmlErweiterung (aber ignorieren .css, .jsusw.).

Danke für die Hilfe!


1
Woher kommt das Diagramm? Ich habe es gerade noch git add .einmal versucht , und es stellte eine gelöschte Datei kein Problem bereit, anders als die Xin dieser Zeile vorschlagen würde.
David

@ David Dieses Bild stammt aus dieser Antwort und gilt für ältere Versionen von Git.
Jerry

4
Bild veraltet! Git 2.x ist anders: i.stack.imgur.com/KwOLu.jpg
Hannes Schneidermayer

Antworten:


131

add *bedeutet, dass alle Dateien im aktuellen Verzeichnis hinzugefügt werden, mit Ausnahme von Dateien, deren Name mit einem Punkt beginnt. Dies ist Ihre Shell-Funktionalität und Git erhält immer nur eine Liste von Dateien.

add . hat keine besondere Bedeutung in Ihrer Shell, und daher fügt Git das gesamte Verzeichnis rekursiv hinzu, was fast gleich ist, jedoch Dateien enthält, deren Namen mit einem Punkt beginnen.


6
git add .Fügt also alle Dateien, Ordner und Unterordner hinzu, einschließlich .gitignore und alles andere, was mit einem Punkt beginnt, während git add *Dateien, Ordner und Unterordner hinzugefügt werden, außer denen, die mit einem Punkt beginnen? Ist das richtig?
Tyler Youngblood

9
Das ist in der Tat richtig. Außerdem git add *würden weiterhin Dateien hinzugefügt, die mit einem Punkt beginnen, wenn sie sich in einem Unterverzeichnis befinden.
Denis

4
git add .respektiert auch .gitignore, wohingegen git add *ein Fehler ausgelöst wird, wenn Nicht-Punkt-Dateien gitignored werden. Viel besser zu bedienen git add .als git add *.
Rosuav

2
Bemerkenswert: Wenn Sie Git unter DOS / Windows von CMD.EXE aus aufrufen, ist es Git , nicht die Shell, die das erweitert *. In diesem Fall findet Git Punktedateien.
Torek

2
@ Thor84no: Git findet die Punktedateien auch auf einem Linux-System, wenn Sie die zitieren *, um sie vor der Shell zu schützen. Es geht nicht um das Verborgene, sondern nur darum, dass sich die kompilierten Regeln von Git unterscheiden.
Torek

30

*ist nicht Teil von git - es ist ein Platzhalter, der von der Shell interpretiert wird. *Erweitert sich auf alle Dateien im aktuellen Verzeichnis und wird erst dann an git übergeben, das addsie alle sind. .ist das aktuelle Verzeichnis selbst, und git addwenn es hinzugefügt wird, werden es und alle Dateien darunter hinzugefügt.


1
Gibt es also einen Grund, das Sternchen zu verwenden? Gibt es einen Vorteil, wenn Sie es anstelle eines Punkts verwenden? Oder umgekehrt? Ich bin sicher, ich habe es in einem Tutorial gesehen. Ich hätte nicht gewusst, dass ich es anders benutzen würde. Ich bin kein großer Kommandozeilen-Typ (wie Sie zweifellos erraten haben).
Tyler Youngblood

5
*vermeidet versteckte Dateien (dh Dateien, deren Name mit a beginnt .). In jedem Fall würde ich nur verwenden, wenn Sie keine bestimmten Dateien hinzufügen git add -u(oder git add -Awenn Sie neue Dateien erstellen).
Mureinik

3
Da Sie beide meine Frage beantwortet haben, hatte ich Schwierigkeiten zu entscheiden, wem ich Ehre machen soll. Ich habe Denis unten ausgewählt, weil er weniger Repräsentanten hat als Sie. Also dachte ich, ihm den grünen Scheck zu geben, würde ihm mehr nützen als dir. Ich hoffe das ergibt Sinn? Aber ich schätze beide Erklärungen sehr. Vielen Dank!
Tyler Youngblood

7

Die Verwendung des Punkts . in der Shell bedeutet normalerweise "das aktuelle Verzeichnis".

Wenn Sie das Sternchen *in einer Shell verwenden, wird eine Funktion namens aufgerufen file-globbing. ZB bei Bash macht die Funktion glob()genau das. Die Manpage für glob ( man 7 glob) lautet:

BESCHREIBUNG

Long ago, in UNIX V6, there was a program /etc/glob that would expand 
wildcard patterns.  Soon afterward this became a shell built-in.
These days there is also a library routine glob(3) that will perform this 
function for a user program.

Wildcard-Matching

A string is a wildcard pattern  if it contains one of the characters '?', '*' or '['. 

Globbing

Globbing is the operation that expands a wildcard pattern 
into the list of pathnames matching the pattern.

Das heißt, wenn Sie Argumente an ein Programm in der Befehlszeile übergeben, die das Platzhaltermuster enthalten '?', '*'oder wenn Sie '['zuerst das Platzhaltermuster in eine Liste von Dateien erweitern, geben Sie diese Dateien dann als Argument an das Programm selbst weiter.

Der Unterschied in der Bedeutung zwischen 'git add .'und 'git add *'wird von Denis klar beschrieben :

git adderwartet, dass eine Liste von Dateien hinzugefügt wird. Im obigen Beispiel wird die Shell erweitert *bzw. .gibt das Ergebnis als Parameter für git add an. Der Unterschied besteht nun darin, dass mit git add .git das aktuelle Verzeichnis erweitert wird, während das git add *Globbing von Dateien ausgelöst wird und dies auf alle Dateien und Verzeichnisse erweitert wird, die nicht mit einem Punkt beginnen.


5

Aus Gründen der Klarheit habe ich die Antwort in die folgende Tabelle eingetragen:

Geben Sie hier die Bildbeschreibung ein

Zusätzliche Hinweise (inspiriert vom @ reka18-Kommentar):

Hinweis 1. git add -A und git add -uBefehle, die ohne zusätzliche Parameter ausgeführt werden, sind zusätzliche Verfeinerungen (Unterverzeichnis oder Maskenangabe für den Dateinamen) im Bereich des gesamten Arbeitsverzeichnisses (auch wenn wir den Befehl im Arbeitsunterverzeichnis des Verzeichnisses ausführen).

Hinweis 2. Das .und *sind jeweils der Verzeichnispfad (aktuelles Verzeichnis) und der Platzhalter, die den Pfad des Befehls verdeutlichen. Wenn der Befehl git add .oder beispielsweise git add *in einem Unterverzeichnis eines Arbeitsverzeichnisses ausgeführt wird, wird deren Aktion nur in diesem Unterverzeichnis verwendet, nicht im gesamten Arbeitsverzeichnis.

Hinweis 3. Der git add -Aund git add -uBefehle können durch einen Pfad hinzufügen oder für Dateien, beispielsweise Maske verfeinert werden git add -A app/controllersoder git add -u app\styles\*.


2
Also ab Git v2.x git add -Aund git add .sind identisch?
reka18

Vielen Dank an reka18 für eine sehr gute Frage. Es hat mich dazu inspiriert, meine Antwort zu vervollständigen ... Die Antwort auf Ihre Frage: Wenn Sie sie im Arbeitsverzeichnis aufrufen, nein, aber wenn Sie sich in einem Unterverzeichnis befinden, dann ja ( git add -Agilt für das gesamte Arbeitsverzeichnis und git add .immer für das aktuelle Verzeichnis).
Simhumileco

2
  • git add -A (--all) Fügt alles hinzu, sodass alles in Ihrem Ordner auf der Festplatte im Staging-Bereich dargestellt wird

  • git add . Stuft alles bereit, entfernt jedoch keine Dateien, die von der Festplatte gelöscht wurden

  • git add * Stuft alles bereit, aber keine Dateien, die mit einem Punkt beginnen, und entfernt keine Dateien, die von der Festplatte gelöscht wurden

  • git add -u (--update) Stuft nur geänderte Dateien ein, entfernt Dateien, die von der Festplatte gelöscht wurden, fügt keine neuen hinzu

  • git add <file name 1> <file name 2> Fügt nur bestimmte Dateien hinzu

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.