Testeur de motifs .gitignore｜Visualisez la règle qui décide réellement de chaque chemin

Collez vos règles .gitignore et une liste de chemins, et l'outil affiche pour chaque chemin Ignoré ou Conservé, accompagné de la règle exacte (et de son numéro de ligne) qui a produit la décision. Conçu pour vérifier les chaînes de négation comme *.log + !important.log, les motifs ne ciblant qu'un dossier comme node_modules/, et les globs récursifs **/ avant de committer une modification du .gitignore.

💡 À propos de cet outil

Un fichier .gitignore cache plusieurs pièges qui se manifestent tard : l'ordre des règles décide du résultat final (c'est la dernière correspondance qui l'emporte, pas la première), la barre oblique finale change le sens du motif, et les globs **/ peuvent matcher trop large ou trop étroit selon ce qui suit. Lancer git check-ignore -v chemin par chemin est utile quand on cible un fichier précis, mais pénible après une refonte d'un .gitignore de 50 lignes lorsqu'on veut voir l'ensemble des conséquences en parallèle.

Le testeur prend le jeu complet de règles à gauche et une liste de chemins à droite, puis affiche chaque verdict en regard de la règle qui l'a produit. Les règles négatives sont marquées [négation], les règles « dossier seulement » ne matchent que des chemins de type dossier, et les motifs invalides apparaissent dans un bandeau rouge en tête de résultat sans interrompre l'évaluation des autres règles.

🧐 Questions fréquentes

Q. La précédence suit-elle celle de git ? R. Oui : les règles sont évaluées de haut en bas, et la dernière correspondance gagne. *.log suivi de !important.log conserve important.log ; dans l'ordre inverse, il est ignoré.

Q. Comment fonctionne le motif « dossier seulement » (node_modules/) ? R. Les motifs terminant par / ne matchent que des chemins de type dossier. Un fichier nommé node_modules (sans barre finale) n'est pas concerné. Un chemin comme node_modules/lodash/index.js apparaît bien comme ignoré avec la ligne de la règle affichée.

Q. Comment se comportent les globs **/ ? R. **/foo matche foo à toute profondeur, foo/** matche tout ce qui se trouve sous foo/. La spécification est dans la page de manuel gitignore(5). Essayez **/build/ avec a/build/x et a/b/build/y pour confirmer.

Q. Que se passe-t-il si un motif a une erreur ? R. Les motifs invalides ([ non fermé, échappements mal formés) sont listés dans un bandeau rouge en tête de résultat. L'évaluation se poursuit pour les règles restantes.

Q. Peut-on tester plusieurs fichiers .gitignore à la fois ? R. Le testeur évalue un seul jeu de règles. Si vous avez un .gitignore à la racine et un autre dans un sous-dossier, collez-les ensemble dans l'ordre racine → sous-dossier ; les règles locales gagnent naturellement puisqu'elles sont évaluées en dernier.

Q. Pourquoi un chemin avec / initial ne matche-t-il pas ? R. Les / et ./ en tête de chemin sont normalisés et retirés. Pour ancrer à la racine du dépôt, placez le / côté motif (par exemple /dist/).

📚 Le saviez-vous : autour de .gitignore

Le fichier .gitignore est présent dans git depuis 2005, mais la grammaire canonique vit dans la page de manuel gitignore(5), pas dans le README. Une subtilité piège même les développeurs expérimentés : si un dossier parent est ignoré, aucune règle !parent/enfant placée à l'intérieur ne peut le réinclure. C'est pour cette raison que le dépôt officiel github/gitignore, qui héberge les modèles pour Node, Python, Java, Unity et beaucoup d'autres écosystèmes, garde les négations près des règles qu'elles annulent et jamais profondément dans un dossier déjà exclu.

Autre piège récurrent qu'on lit sur les forums francophones : git fonctionne en last-match-wins, pas en first-match-wins. Si vous copiez un modèle de github/gitignore puis ajoutez vos propres règles à la fin, vous pouvez sans le vouloir réignorer quelque chose que le modèle dés-ignorait plus haut. Passer le jeu de règles et un échantillon de chemins par ce testeur avant le commit rend la chaîne d'override visible : chaque ligne de résultat indique précisément la règle qui a décidé du verdict, et un faux pas se repère sans avoir à relancer git check-ignore fichier par fichier.