0

Gitignore Tester

Klistra in dina .gitignore-regler och en lista över filsökvägar för att se exakt vilka filer som ignoreras, av vilken regel och rad, och vilka negationsregler som är tyst verkningslösa för att en överordnad katalog redan ignoreras.

🔒 Bearbetas helt i din webbläsare – ingenting du anger här laddas någonsin upp.

Bearbetar... 0%
Tolkar .gitignore-regler
Matchar filsökvägar
Klart

Resultat

"Varför fungerar inte min .gitignore-negation?" är en av de vanligaste git-frågorna, och svaret är nästan alltid detsamma: ett `!mönster` som försöker återinkludera en fil i en katalog som redan uteslutits av en tidigare regel kan aldrig fungera, eftersom git inte går ner i ignorerade kataloger för att kontrollera något inuti dem igen. Det här verktyget återskapar gits faktiska .gitignore-matchningsalgoritm – inte en approximation – just för att kunna fånga och förklara den situationen, tillsammans med alla andra mönsterregler som git stöder.

Klistra in dina .gitignore-regler i en ruta och en lista över filsökvägar (en per rad, som `dist/index.js`, `node_modules/foo/bar.js` eller `.env`) i den andra, så utvärderar verktyget varje sökväg precis som git skulle göra: kommentarer och tomma rader hoppas över, avslutande blanksteg tas bort om de inte är escape:ade, ett inledande `!` negerar en regel, ett inledande `/` ankrar den till roten istället för att matcha på valfritt djup, ett avslutande `/` begränsar den till kataloger, och `*`, `?`, `[abc]`-teckenklasser och `**` (som matchar över kataloggränser) fungerar enligt de dokumenterade globreglerna.

Avgörande är att sökvägar kontrolleras katalog för katalog från roten och nedåt, samma sätt som gits egen ignore-motor fungerar – inte genom att testa hela sökvägen mot varje regel isolerat. Det är vad som gör det möjligt att korrekt upptäcka fallet med död negation: om `dist/` ignoreras på rad 3 och en senare `!dist/keep.js` försöker rädda en fil inuti den, rapporterar detta verktyg `dist/keep.js` som fortfarande ignorerad, namnger regeln på rad 3 som orsaken, och flaggar separat negationen som överskuggad istället för att tyst låtsas att den fungerade.

Resultattabellen ger varje testad sökväg en egen rad med ett tydligt ja/nej-utslag, den exakta regeltexten och radnumret som avgjorde det, och – när det är relevant – en not på klarspråk som förklarar en överskuggad negation eller en ärvd regel från överordnad katalog. Det är detaljnivån som förvandlar en förvirrande .gitignore till en du faktiskt kan resonera kring innan du commitar.