A meno che un repo non sia composto da diversi progetti indipendenti, sembra che sarebbe più semplice avere un solo .gitignorefile nella radice del repository rispetto a vari progetti in tutto. Esiste una best practice standard su questa o alcune analisi online di quando un approccio è migliore dell'altro?
Risposte:
Posso pensare ad almeno due situazioni in cui vorresti avere più .gitignorefile in diverse (sotto) directory.
Directory diverse hanno diversi tipi di file da ignorare. Ad esempio, .gitignorenella directory superiore del progetto ignora i programmi generati, mentre Documentation/.gitignoreignora la documentazione generata.
Ignora dato file solo nella data directory (sub) (è possibile utilizzare /sub/fooin .gitignore, però).
Ricorda che i pattern nel .gitignorefile si applicano in modo ricorsivo alla (sotto) directory in cui si trova il file e in tutte le sue sottodirectory, a meno che il pattern contenga '/' (quindi, ad esempio, il pattern si nameapplica a tutti i file nominati namein una determinata directory e tutte le sue sottodirectory, mentre si /nameapplica al file con questo nome solo nella directory indicata).
Documentation/**/*.html(nota che qualsiasi barra fissa il modello; /fooviene usato per ancorare il file direttamente nella directory)
Come nota tangenziale, un caso in cui la possibilità di avere più .gitignorefile è molto utile è se si desidera una directory aggiuntiva nella copia di lavoro che non si intende mai eseguire il commit. Basta inserire un 1 byte .gitignore(contenente un solo asterisco) in quella directory e non verrà mai visualizzato in git statusecc.
printf \* > .gitignore(la pulizia è automatica quando elimini la directory). Sono certo che ci sono situazioni in cui .git/info/excludeè la scelta più appropriata, ma non molte.
Puoi averne più .gitignore, ognuna ovviamente nella sua directory.
Per controllare quale regola gitignore è responsabile per aver ignorato un file, uso git check-ignore: git check-ignore -v -- afile.
E puoi avere una versione diversa di un .gitignorefile per ramo: ho già visto quel tipo di configurazione per garantire che un ramo ignori un file mentre l'altro ramo non lo fa: vedi ad esempio questa domanda .
Se il tuo repository include diversi progetti indipendenti, sarebbe comunque meglio fare riferimento a loro come sottomoduli .
Quelle sarebbero le migliori pratiche effettive, consentendo a ciascuno di quei progetti di essere clonato in modo indipendente (con i loro rispettivi .gitignorefile), pur facendo riferimento a una revisione specifica in un progetto padre globale.
Scopri la vera natura dei sottomoduli per ulteriori informazioni.
Nota che, da git 1.8.2 (marzo 2013), puoi fare una cosa git check-ignore -v -- yourfileper vedere a quale gitignore eseguire (da quale .gitignorefile) viene applicato ' yourfile', e capire meglio perché quel file viene ignorato.
Vedi " quale gitignoreregola ignora il mio file? "
Pro singolo
Facile da trovare.
Cercare le regole di esclusione può essere abbastanza difficile se ho più gitignore, a diversi livelli nel repository.
Con più file, in genere si finisce anche con un bel po 'di duplicazione.
Pro multiplo
Ambiti "conoscenza" alla parte dell'albero dei file in cui è necessaria.
Poiché Git tiene traccia solo dei file, un .gitignore vuoto è l'unico modo per eseguire il commit di una directory "vuota".
(E prima di Git 1.8, l'unico modo per escludere un modello simile my/**.exampleera crearlo my/.gitignorecon il modello **.foo. Questo motivo non si applica ora, come puoi fare /my/**/*.example.)
Preferisco di gran lunga un singolo file, dove posso trovare tutte le esclusioni. Non ho mai perso per-directory .svn e non perderò neanche per-directory .gitignore.
Detto questo, più gitignores sono abbastanza comuni. Se li usi, almeno sii coerente nel loro uso per renderli ragionevoli con cui lavorare. Ad esempio, puoi metterli nelle directory solo a un livello dalla radice.
emptyper questo) sia più comune.
Ci sono molti scenari in cui si desidera impegnarsi in una directory a vostra repo Git, ma senza i file in essa contenuti, ad esempio, il logs, cache, uploadsdirectory ecc
Quindi quello che faccio sempre è aggiungere un .gitignorefile in quelle directory con il seguente contenuto:
*
!.gitignore
Con questo .gitignorefile, Git non traccia i file in quelle directory, ma mi consente comunque di aggiungere il .gitignorefile e quindi la directory stessa al repository.