2016-01-20 12 views
13

Hier ist der Inhalt meines aktuellen Verzeichnisses.Welches Muster folgt .gitignore?

$ ls 
foo.foo 
$ ls -a 
. .. .bar.foo .foo foo.foo .gitignore 

Dann mache ich dieses Verzeichnis in ein Git-Repository.

$ git init 
Initialized empty Git repository in /home/lone/foo/.git/ 
$ ls -a 
. .. .bar.foo .foo foo.foo .git .gitignore 

Hier ist der Inhalt von .gitignore.

$ cat .gitignore 
*.foo 

I sehen, dass das Muster in .gitignore in der Schale unterschiedlich von dem gleichen Muster verhält. In der Shell *.foo werden nur nicht versteckte Dateien abgeglichen, d. H. Dateinamen, die nicht mit einem Punkt beginnen.

$ echo *.foo 
foo.foo 

Aber *.foo in .gitignore scheint alle Dateien, versteckte oder nicht versteckt zu entsprechen, die mit .foo endet.

$ git status 
On branch master 

Initial commit 

Untracked files: 
    (use "git add <file>..." to include in what will be committed) 

     .gitignore 

nothing added to commit but untracked files present (use "git add" to track) 

Wo kann ich mehr über die genaue Definition der Muster, die .gitignore folgt, so dass ich kann verstehen, wo und warum ihr Verhalten von dem das Muster Schal glob unterscheidet?

+3

Hier ist eine Ressource: https://git-scm.com/docs/gitignore. Unter bestimmten Bedingungen wird es genau wie ein Shell-Glob behandelt. "Ansonsten behandelt Git das Muster als einen Shell-Glob, der für den Konsum von fnmatch (3) mit dem FNM_PATHNAME-Flag geeignet ist" (Aber lies das Zeug darüber, wenn es das nicht tut) – hiandbaii

+0

@hiandbaii Ich habe diese Dokumentation gelesen, bevor ich diese Frage gestellt habe . Einige Dinge sind mir jedoch nicht klar. Verwendet die Shell auch 'fnmatch (3)', um Glob-Patterns zu verarbeiten? Warum stimmt '*' dann nicht mit null Zeichen vor '.' überein (d. H. Versteckte Dateien), aber Gitignore? Ich kann den genauen Abschnitt in der Dokumentation "Gitignore" nicht finden, der dies erklärt. –

Antwort

9

gitignore Verwendung von '*' folgt die glob convention:

Git behandelt das Muster als eine Schale glob geeignet für den Verzehr durch fnmatch(3) mit dem FNM_PATHNAME flag: Platzhalter im Muster passt nicht zu / im Pfadnamen.

Zum Beispiel: "Documentation/*.html" matches "Documentation/git.html", aber nicht "Documentation/ppc/ppc.html" oder "tools/perf/Documentation/perf.html".

Die OP Lone Learner fragt in the comments:

Hat auch die Shell verwenden fnmatch(3) glob Muster zu verarbeiten?
In diesem Fall warum * nicht Null Zeichen zuvor entsprechen. (d. h. versteckte Dateien) aber Gitignore tut?

Denn das ist ein shell configuration choice.

Typ (mit shopt, die specific to bash ist):

shopt -s dotglob 
echo *.foo 
.foo foo.foo 

Das dotglob unter Verwendung

Wenn gesetzt, Bash Dateinamen mit einem '.' beginnend enthält in den Ergebnissen der filename expansion . (für pattern matching)

3

.gitignore einfach enthält Einträge für das Muster, das Sie wollen sagen git nicht (Platzhalter unterstützen) zu verfolgen.

Diese Konfiguration wird auf Ordnerebene gespeichert.
Dort können Sie angeben, welche Datei ignoriert werden soll.
Diese Datei wird auf alle rekursiven Unterordner angewendet.

.gitignore wird, um Informationen in einer kommutativen Weise zu sammeln:

  • System level - (Global) zum Beispiel, wenn Sie ein Unix-Benutzer sind und Sie möchten alle *.so Dateien für alle Ihre Projekte ignorieren Sie legen sie sie in der globalen Datei

  • Lokale - auf Projektebene wird in der Regel für alle Inhalte des gegebenen Projektes anwenden.

  • Per Ordner - spezifische Definitionen für den angegebenen Ordner (zum Beispiel - Passwort-Datei ignorieren, Protokolldatei usw. oder jede andere Ressource, die Sie ignorieren mögen)

Es gibt auch eine Konfigurationseigenschaft core.excludesfile mit denen Sie auch eine ignorierte Datei festlegen können.

git config --global core.excludesfile ~/.gitignore

Sie können auch angeben, welche Dateien nicht zu ignorieren, indem die ! vor der Datei hinzufügen, damit es nicht ignoriert wird (mehr unter etwa dem Platzhalter lesen whic verwendet werden kann).

Um mehr über die Syntax zu erfahren, können Sie darüber lesen here.
Sie können 3rd-Part-Tools verwenden, um diese Datei für Sie gitignore.io zu generieren.


ich nicht, was auf der Seite finden konnte, erklärt, dass * entspricht null oder mehr Zeichen und versteckte Dateien paßt zu

Jede Zeile in der Datei mit einem beliebigen Muster mit den folgenden Platzhalter enthalten :

? = null oder ein Auftreten der gegebenen Muster.
* = Entspricht null oder mehr Vorkommen der angegebenen Muster.
+ = Entspricht einem oder mehreren Vorkommen der angegebenen Muster.
@ = Entspricht einem der angegebenen Muster.
! = Entspricht allem außer einem der angegebenen Muster.


In Ihrem Kommentar fragen Sie nach Informationen über die * Muster.

Hier können Sie sehen, dass die * alle Dateien ignorieren. Git ist es egal, ob es eine versteckte Datei ist oder nicht. es sucht einfach nach dem passenden Muster.

enter image description here

Wie oben erklärt git versuchen, das Muster, das Sie in der .gitignore Datei liefern passen so, wenn Sie Dateien in einem inneren Ordner ignorieren möchten, werden Sie den inneren Ordner angeben. Hier ist eine Demo des Ordnerinhaltes und wie man innere Dateien ignoriert. Sie können sehen, dass der innere Ordner aa die Datei enthält, aber da die Ignorierdatei das **/ Muster enthält, werden alle internen Ordner und Dateien ignoriert.

enter image description here

+0

Ich habe diese Dokumentation gelesen, bevor ich diese Frage gestellt habe. Ich konnte nicht finden, was auf der Seite erklärt, dass '*' mit null oder mehr Zeichen übereinstimmt und auch versteckte Dateien zusammenbringt. –

+0

Weitere Details zum Platzhalter asterisk hinzugefügt. Fühlen Sie sich frei zu fragen, ob etwas immer noch nicht klar ist – CodeWizard

+1

Als eine Faustregel schnüffelt git alle Dateien in einer bestimmten Ordnerstruktur (Linux oder Windows) und wird diese standardmäßig in die Quellcodeverwaltung einschließen, sofern sie nicht explizit in .gitignore ignoriert werden. In diesem Fall gilt die Regel für versteckte und sichtbare Ordner. Da * * null oder mehr Zeichen entspricht ... habe ich persönlich weder die Git-Spezifikationen noch die gesamte Dokumentation gelesen, aber ich denke, einige Dinge können aus dem Verhalten der zugrundeliegenden Dateisysteme abgeleitet werden, besonders unter Linux. – Eniola