Tester per .gitignore

"Perché la mia negazione nel .gitignore non funziona?" è una delle domande più comuni su git, e la risposta onesta è quasi sempre la stessa: un `!pattern` che tenta di ri-includere un file all'interno di una cartella che una regola precedente ha già escluso non può mai funzionare, perché git non scende nelle cartelle ignorate per ricontrollare ciò che contengono. Questo strumento reimplementa l'effettivo algoritmo di matching di .gitignore di git — non un'approssimazione — proprio per poter individuare e spiegare quella situazione esatta, insieme a ogni altra regola di pattern supportata da git.

Incolla le tue regole di .gitignore in un riquadro e un elenco di percorsi di file (uno per riga, come `dist/index.js`, `node_modules/foo/bar.js` o `.env`) nell'altro, e lo strumento valuta ogni percorso esattamente come farebbe git: commenti e righe vuote vengono saltati, gli spazi finali vengono rimossi a meno che non siano preceduti da escape, un `!` iniziale nega una regola, uno `/` iniziale la ancora alla radice invece di consentire la corrispondenza a qualsiasi profondità, uno `/` finale la limita alle cartelle, e `*`, `?`, le classi di caratteri `[abc]` e `**` (corrispondenza attraverso i confini delle cartelle) funzionano tutti secondo le regole glob documentate.

Fondamentalmente, i percorsi vengono controllati cartella per cartella dalla radice verso il basso, nello stesso modo in cui opera il motore di ignore di git — non testando l'intero percorso contro ogni regola in modo isolato. Questo è ciò che rende possibile rilevare correttamente il caso della negazione morta: se `dist/` viene ignorata alla riga 3 e un successivo `!dist/keep.js` tenta di salvare un file al suo interno, questo strumento segnala `dist/keep.js` come ancora ignorato, nomina la regola alla riga 3 come causa e segnala separatamente la negazione come oscurata, invece di fingere silenziosamente che abbia funzionato.

La tabella dei risultati assegna a ogni percorso testato una propria riga con un chiaro verdetto sì/no ignorato, il testo esatto della regola e il numero di riga che lo ha deciso e, quando pertinente, una nota in linguaggio chiaro che spiega una negazione oscurata o una regola ereditata dalla cartella padre. Questo è il dettaglio che trasforma un .gitignore confuso in uno su cui puoi effettivamente ragionare prima di fare commit.