Generatore Gitignore
Scegli il tuo stack, sistema operativo ed editor e ottieni un .gitignore pulito e deduplicato con un clic.
Cos'è un file .gitignore?
Un file .gitignore indica a Git quali percorsi escludere dal controllo di versione. Risiede nella radice del repository ed è esso stesso versionato — così ogni clone applica le stesse regole. Senza di esso, finisci per tracciare binari compilati, cartelle di dipendenze, cache degli IDE, file di log e (peggio di tutto) segreti come i file .env. Una volta che entrano nella cronologia, possono restare consultabili per sempre, anche dopo un force-push, ed è per questo che impostare correttamente .gitignore all'inizio del progetto conta più di quanto si pensi. Questo generatore unisce pattern collaudati per i linguaggi, framework, sistemi operativi ed editor che usi davvero, poi deduplica le intestazioni così il file resta leggibile. Produce solo pattern di percorso — mai codice sorgente — quindi è sicuro inserirlo direttamente in un repo pubblico. Se il tuo progetto mescola un backend, un frontend, due sistemi operativi e tre editor distribuiti nel team, basta selezionarli tutti: il risultato è un singolo file, non una cartella, e Git considera ogni riga come additiva. Puoi incollarlo come punto di partenza e adattarlo da lì.
Come usarlo
1. Scegli i tuoi template
Clicca su qualsiasi chip dalle liste di linguaggi, sistemi operativi o editor. Usa il campo di filtro in alto se la lista è lunga — fa corrispondere sia l'etichetta sia la chiave interna.
2. Rivedi l'output
Ogni template ha la propria intestazione di sezione commentata (# === Node.js ===) così puoi capire a colpo d'occhio da dove provengono le regole. L'ordine è quello in cui hai cliccato.
3. Copia o scarica
Copia tutto negli appunti, oppure premi Scarica per salvarlo direttamente come .gitignore. Inseriscilo nella radice del tuo repo prima del primo commit.
4. Adatta al bisogno
Considera l'output come un punto di partenza. Aggiungi in fondo i percorsi specifici del progetto (upload, documenti generati, file temporanei) e rimuovi qualsiasi regola che non si applica al tuo setup.
Cosa fa ciascuna regola
I pattern in .gitignore seguono regole semplici. Un percorso letterale come node_modules/ ignora quella directory ovunque appaia. Una barra iniziale (/dist) ancora il pattern alla radice del repo. I caratteri glob funzionano come previsto: *.log corrisponde ai file per estensione, **/cache ricorre, e parentesi quadre come *.[oa] corrispondono a un set di caratteri. Un ! iniziale nega una regola precedente, ed è così che Unity mantiene i file .meta anche quando il loro target è ignorato. Le righe che iniziano con # sono commenti. Le barre finali significano “solo directory”. I file già tracciati non sono interessati — per rimuovere un file dal tracciamento dopo averlo aggiunto a .gitignore, esegui git rm --cached percorso.
Quando aggiungere cosa
Scegli i template di linguaggio e framework per gli artefatti di build e le cartelle di dipendenze (node_modules/, vendor/, target/). Aggiungi il template del sistema operativo per i sistemi che il tuo team usa — macOS lascia .DS_Store ovunque e Windows sparge Thumbs.db. Aggiungi un template di editor per qualunque IDE il team standardizzi; se le persone usano un mix, aggiungili tutti. Come regola generale: almeno uno stack + un sistema operativo + un editor per ogni nuovo repo. Evita di ignorare i lockfile (package-lock.json, composer.lock, Gemfile.lock) — quelli vanno versionati per build riproducibili.
Domande frequenti
Verrà versionato qualcosa del mio codice?
.gitignore.Dove posiziono il file?
.gitignore (con il punto iniziale). Puoi avere ulteriori file .gitignore nelle sottodirectory — Git applica quello più vicino a ciascun percorso.Ho già committato file che avrei dovuto ignorare. Cosa faccio?
.gitignore, poi esegui git rm --cached percorso per smettere di tracciare il file (resta su disco). Committa quello, e da quel momento Git lo lascerà in pace. Per i segreti che sono già finiti nella cronologia, ruotali e riscrivi la cronologia con git filter-repo.Devo committare anche il file .gitignore stesso?
.gitignore sono le regole condivise — ogni contributore ha bisogno dello stesso file. Committalo come qualsiasi altro file sorgente.E i lockfile?
package-lock.json, yarn.lock, composer.lock, Gemfile.lock, poetry.lock) vanno versionati, non ignorati. Bloccano le versioni esatte così tutti ottengono la stessa build. I template qui non ignorano i lockfile per impostazione predefinita — Rails è l'eccezione storica in alcune configurazioni, e manteniamo la convenzione upstream.Mi serve anche un gitignore globale?
.gitignore globale (configurato con git config --global core.excludesFile) è il posto giusto per il rumore personale di editor e sistema operativo, così non devi ripeterlo in ogni repo. Le regole a livello di progetto dovrebbero comunque coprire le impostazioni di linguaggio, framework ed editor a livello di team.