Testeur Gitignore

"Pourquoi ma négation .gitignore ne fonctionne-t-elle pas ?" est l'une des questions git les plus courantes, et la réponse honnête est presque toujours la même : un `!pattern` essayant de réinclure un fichier dans un répertoire qu'une règle antérieure exclut déjà ne peut jamais fonctionner, car git ne descend pas dans les répertoires ignorés pour revérifier quoi que ce soit à l'intérieur. Cet outil réimplémente l'algorithme de correspondance .gitignore réel de git - et non une approximation - spécifiquement pour pouvoir détecter et expliquer cette situation exacte, ainsi que toutes les autres règles de modèle prises en charge par git.

Collez vos règles .gitignore dans une case et une liste de chemins de fichiers (un par ligne, comme `dist/index.js`, `node_modules/foo/bar.js` ou `.env`) dans l'autre, et l'outil évalue chaque chemin exactement comme le ferait git : les commentaires et les lignes vides sont ignorés, les espaces de fin sont supprimés à moins d'être échappés, un `!` de début annule une règle, un `/` d'ancrage de début à la racine au lieu de le laisser correspondre à n'importe quelle profondeur, un `/` final le restreint aux répertoires, et les classes de caractères `*`, `?`, `[abc]` et `**` (correspondance à travers les limites du répertoire) fonctionnent toutes selon les règles globales documentées.

Il est important de noter que les chemins sont vérifiés répertoire par répertoire à partir de la racine, de la même manière que fonctionne le moteur d'ignorance de git - et non en testant le chemin complet par rapport à chaque règle de manière isolée. C'est ce qui permet de détecter correctement le cas de négation morte : si `dist/` est ignoré à la ligne 3 et qu'un `!dist/keep.js` ultérieur tente de sauver un fichier à l'intérieur, cet outil signale `dist/keep.js` comme toujours ignoré, nomme la règle de la ligne 3 comme raison et marque séparément la négation comme masquée plutôt que de prétendre silencieusement qu'elle a fonctionné.

Le tableau des résultats donne à chaque chemin testé sa propre ligne avec un verdict clair oui/non ignoré, le texte exact de la règle et le numéro de ligne qui l'a décidé et, le cas échéant, une note en langage clair expliquant une négation masquée ou une règle de répertoire parent héritée. C'est le détail qui transforme un .gitignore déroutant en un .gitignore sur lequel vous pouvez réellement raisonner avant de vous engager.