2016-01-20 18 views
13

Ecco il contenuto della mia directory corrente.Quale modello segue .gitignore?

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

Quindi trasformo questa directory in un repository git.

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

Questo è il contenuto di .gitignore.

$ cat .gitignore 
*.foo 

vedo che il pattern nella .gitignore comporta diversamente dal medesimo modello in guscio. Nella shell *.foo corrisponde solo i file non nascosti, ovvero nomi di file che non iniziano con un punto.

$ echo *.foo 
foo.foo 

Ma *.foo in .gitignore sembra corrispondere qualsiasi file, nascosti o non nascoste, che termina con .foo.

$ 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) 

Dove posso saperne di più sulla definizione precisa dei modelli che .gitignore segue, in modo che io possa capire dove e perché il suo comportamento è diverso da quello dei modelli della shell glob?

+3

Ecco una risorsa: https://git-scm.com/docs/gitignore. Sotto certe condizioni viene trattato esattamente come un guscio glob. "Altrimenti, Git tratta il pattern come una shell glob adatta al consumo da fnmatch (3) con il flag FNM_PATHNAME" (ma leggi le cose sopra per quando non lo fa) – hiandbaii

+0

@hiandbaii Ho letto quella documentazione prima di fare questa domanda . Tuttavia, un paio di cose non mi sono chiare. La shell usa anche 'fnmatch (3)' per elaborare i glob pattern? In tal caso, perché '*' non corrisponde a zero caratteri prima di '.' (cioè i file nascosti) ma gitignore fa? Non riesco a trovare la sezione precisa nella documentazione 'gitignore' che spiega questo. –

risposta

9

gitignore uso di '*' segue la glob convention:

Git considera il modello come glob shell adatto per il consumo da fnmatch(3) con i FNM_PATHNAME flag: jolly nel modello non corrisponderà a / nel nome del percorso.

Ad esempio, "Documentation/*.html" corrisponde a "Documentation/git.html" ma non "Documentation/ppc/ppc.html" o "tools/perf/Documentation/perf.html".

Il OP Lone Learner chiede in the comments:

Conviene la shell anche utilizzare fnmatch(3) per elaborare modelli glob?
In tal caso, perché * non corrisponde a zero caratteri prima. (cioè i file nascosti) ma gitignore fa?

Perché questo è un shell configuration choice.

Tipo (usando shopt, che è specific to bash):

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

che utilizza dotglob

Se impostata, bash include i nomi di file che iniziano con un '.' nei risultati di filename expansion . (per pattern matching)

3

.gitignore contiene semplicemente voci per il modello che si desidera tell git da non tracciare (supporto caratteri jolly).

Questa configurazione è archiviata a livello di cartella.
Qui è possibile specificare quale file ignorare.
Questo file verrà applicato a tutte le sottocartelle all'interno in modo ricorsivo.

.gitignore sta raccogliendo le informazioni in un modo commutativa:

  • System level - (Global) per esempio se sei un utente unix e si desidera ignorare tutti i file *.so per tutti i vostri progetti si vuole posizionarlo nel file globale

  • Locale - Di solito sarà a un livello di progetto che si applica per tutto il contenuto del progetto specificato.

  • Per cartella - definizioni specifiche per la cartella data (ad esempio - ignorare file delle password, accedere etc file o qualsiasi altra risorsa che si desidera ignorare)

C'è anche una proprietà di configurazione core.excludesfile che ti permettono di impostare un file ignorato da usare pure.

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

È inoltre possibile specificare quali file non ignorare aggiungendo il ! prima che il file in modo che non essere ignorato (per saperne di più sotto circa i caratteri jolly whic possono essere utilizzati).

Per informazioni sulla sintassi è possibile leggere a riguardo here.
È possibile utilizzare strumenti di terze parti per generare questo file per voi gitignore.io.


non riuscivo a trovare quello che nella pagina spiega che * corrisponde a zero o più caratteri e corrisponde file nascosti troppo

Ogni riga nel file può contenere qualsiasi modello con i seguenti caratteri jolly :

? = zero o un'occorrenza dei pattern dati.
* = Corrisponde a zero o più occorrenze dei motivi specificati.
+ = Corrisponde a una o più occorrenze dei motivi specificati.
@ = Corrisponde a uno dei motivi indicati.
! = Corrisponde a qualsiasi elemento tranne uno dei motivi specificati.


nel tuo commento hai chiesto informazioni sul * modello.

Qui puoi vedere che lo * ignora tutti i file. A Git non importa se è un file nascosto o no. sta semplicemente cercando il modello abbinato.

enter image description here

Come spiegato in precedenza git cercare di far corrispondere il modello si fornisce nel file .gitignore quindi se si desidera ignorare i file in una cartella interna si dovrà specificare la cartella interna. Ecco una demo del contenuto della cartella e come ignorare i file interni. È possibile vedere che la cartella interna aa contiene file all'interno, ma poiché il file di ignora contiene il modello **/, ignorerà tutte le cartelle ei file interni.

enter image description here

+0

Ho letto quella documentazione prima di fare questa domanda. Non ho trovato quello che nella pagina spiega che '*' corrisponde a zero o più caratteri e corrisponde anche ai file nascosti. –

+0

Aggiunti ulteriori dettagli sull'asterisco con caratteri jolly. Sentiti libero di chiedere se qualcosa non è ancora chiaro – CodeWizard

+1

Come regola generale git annusa tutti i file in una determinata struttura di cartelle (Linux o Windows) e per impostazione predefinita li include sotto il controllo del codice sorgente a meno che non vengano esplicitamente ignorati in .gitignore. In tal caso, la regola verrà applicata a entrambe le cartelle nascoste e visibili. Quindi dal momento che * corrisponde a zero o più caratteri ... Personalmente non ho letto le specifiche git o tutta la documentazione, ma penso che alcune cose possano essere dedotte dal comportamento dei filesystem sottostanti, specialmente su Linux. – Eniola