block Generatore di .gitignore star

Come Funziona

Spunta le caselle che corrispondono al tuo progetto — un linguaggio o runtime come Node.js, Python o Java, un sistema operativo come macOS, Windows o Linux, un editor come VS Code o IntelliJ/JetBrains, più un blocco per i file residui di Git stesso e uno per .env e le credenziali. Ogni casella aggiunge un piccolo insieme di pattern di esclusione consolidati, presi dalle convenzioni che la comunità usa davvero — node_modules/ per Node, __pycache__/ e .venv/ per Python, *.class e target/ per Java, .DS_Store per macOS, Thumbs.db per Windows, e così via. Man mano che selezioni più caselle, lo strumento unisce tutto in un unico elenco, elimina i duplicati esatti e mostra il risultato in tempo reale in una casella di testo che puoi copiare o scaricare direttamente come file chiamato .gitignore.

Il motivo per combinare più categorie invece di scriverne una da zero è che la maggior parte dei progetti reali ricade in diverse categorie contemporaneamente: un'API Node.js sviluppata su un Mac con VS Code ha bisogno del blocco Node per gli artefatti di build, del blocco macOS perché .DS_Store non finisca mai in una pull request, e del blocco VS Code perché le tue impostazioni personali dell'editor non sovrascrivano quelle di un collega. Spuntare tutti e tre e scaricare una sola volta è più veloce e meno soggetto a errori che assemblare a mano i pattern a memoria o incollare frammenti presi da vecchi progetti.

Cose da Sapere

Un file .gitignore influisce solo sui file che Git non conosce ancora — dice a Git quali file non tracciati escludere da git status, git add . e dai commit futuri. Non ha alcun effetto sui file già tracciati (già inclusi in almeno un commit). Questo è il punto di confusione più comune: aggiungere .env a .gitignore dopo che è già stato committato non lo rimuove dal repository né impedisce a Git di continuare a tracciarne le modifiche future. Per smettere davvero di tracciare un file bisogna prima eseguire git rm --cached <file> (che lo rimuove dall'indice di Git ma lo lascia sul disco), fare il commit di quella rimozione, e solo a quel punto la regola corrispondente in .gitignore entra in vigore per il futuro.

La maggior parte dei pattern proposti qui deriva dal repository ufficiale github/gitignore di GitHub, la fonte più consultata per i modelli specifici di linguaggi e strumenti, la stessa collezione che GitHub propone quando crei un nuovo repository dalla sua interfaccia web. Tenere fuori dal controllo di versione cartelle di dipendenze come node_modules/ e output di build come dist/ o target/ è importante per le dimensioni — queste cartelle possono facilmente superare più volte il peso del codice sorgente vero e proprio e si rigenerano banalmente da un file di lock o da uno script di build — mentre tenere fuori file come .env, *.pem e *.key è importante per la sicurezza: committare una credenziale nella cronologia di Git la rende di fatto pubblica per sempre, perché rimuoverla dall'ultimo commit non la cancella da quelli precedenti senza riscrivere completamente la cronologia.