Avviare un repository Node.js
Combina le dipendenze con le uscite del framework usato. Mantieni lockfile e configurazione necessari per installazioni riproducibili.
Seleziona gli ambienti usati nel progetto, aggiungi regole personalizzate e genera un file .gitignore pulito senza duplicati.
Seleziona solo le tecnologie realmente usate dal progetto.
Una regola per riga. Ordine e ripetizioni delle regole personali vengono conservati.
Componi un .gitignore per il repository combinando modelli locali e regole personali. Il generatore produce testo da controllare e salvare nel progetto; non apre il repository e non modifica l’indice Git. È utile per dipendenze, compilazioni e cache. Scegli le esclusioni in base ai file realmente generati: una regola utile altrove può nascondere un file che il tuo gruppo deve versionare.
I modelli vengono uniti nell’ordine del catalogo. I duplicati esatti fra modelli vengono eliminati, senza semplificare sovrapposizioni come *.log e un percorso specifico. Le regole personalizzate sono aggiunte alla fine nel loro ordine originale. Le ripetizioni vengono conservate perché un’esclusione ripetuta dopo una negazione può cambiare il risultato. Si mantengono barre inverse e spazi preceduti da escape.
Git interpreta i motivi in base alla posizione del .gitignore. Un / iniziale li ancora a quel punto e uno finale indica una directory. * e ** non hanno sempre lo stesso ambito. ! include nuovamente un percorso escluso, ma Git non può recuperare un file se la directory superiore è completamente ignorata. # iniziale apre un commento; usa l’escape se il nome inizia davvero con quel carattere.
Il modello di ambiente ignora .env e .env.* e poi aggiunge !.env.example, così da versionare un esempio senza segreti. Le regole riguardano soprattutto file non tracciati. Un file già nell’indice resta tracciato anche se corrisponde a un nuovo motivo. Il generatore non rimuove file dall’indice, non ripulisce la cronologia e non cerca segreti.
Scegli soltanto gli ambienti effettivi del progetto. Selezionare ogni tecnologia può introdurre esclusioni troppo ampie.
Inserisci una regola per riga e colloca le negazioni dopo le esclusioni. Puoi attivare o disattivare i commenti di sezione.
Scarica .gitignore, rileggilo e controlla un percorso con git check-ignore -v. Esamina i file già tracciati prima di modificare l’indice.
Combina le dipendenze con le uscite del framework usato. Mantieni lockfile e configurazione necessari per installazioni riproducibili.
Usa i motivi .env e l’eccezione .env.example. Verifica che l’esempio contenga soltanto valori fittizi.
Aggiungi eccezioni nelle regole personali e controllane l’ordine. Confronta il testo con il file attuale prima di sostituirlo.
Senza commenti, il modello environment genera tre righe. L’eccezione segue le esclusioni per mantenere visibile .env.example.
Input
environment; includeComments=falseRisultato
.env
.env.*
!.env.exampleLe regole personali restano in questo ordine. L’ultima esclusione può annullare la precedente inclusione; eliminare il duplicato ne cambierebbe il significato.
Input
custom: *.log
!important.log
*.logRisultato
*.log
!important.log
*.logDi solito alla radice del repository. Git accetta anche .gitignore annidati con motivi relativi alla propria directory. Adatta i percorsi se sposti il file.
Potrebbe essere già tracciato. I motivi non lo rimuovono dall’indice; esamina git ls-files e le modifiche preparate prima di intervenire.
Si eliminano ripetizioni esatte fra modelli. Le regole personali conservano ordine e ripetizioni per rispettare le eccezioni con !.
No. Unisce motivi senza ispezionare file o cronologia. Le esclusioni preventive completano una revisione del repository senza sostituirla.
Strumenti correlati
Strumenti simili o complementari a questo.
Confronta due testi riga per riga e individua subito aggiunte, eliminazioni e modifiche.
Converti i permessi Unix tra notazione ottale e simbolica e genera un comando chmod.
Genera istantaneamente uno o più identificatori UUID v4 casuali e copiali quando serve.