Gitignore tester
Lim inn .gitignore-reglene dine og en liste over filbaner for å se nøyaktig hvilke filer som ignoreres, med hvilken eksakt regel og linje, og hvilke negeringsregler som er stille døde fordi en overordnet katalog allerede er ignorert.
Resultat
"Hvorfor fungerer ikke min .gitignore-nektelse?" er et av de vanligste git-spørsmålene som finnes, og det ærlige svaret er nesten alltid det samme: et `!mønster` som prøver å re-inkludere en fil i en katalog som en tidligere regel allerede ekskluderer, kan aldri fungere, fordi git ikke går ned i ignorerte kataloger for å sjekke noe inni dem på nytt. Dette verktøyet reimplementerer gits faktiske .gitignore-matchingalgoritme – ikke en tilnærming – spesifikt slik at det kan fange opp og forklare den nøyaktige situasjonen, sammen med alle andre mønsterregler som git støtter.
Lim inn .gitignore-reglene dine i den ene boksen og en liste over filstier (en per linje, som `dist/index.js`, `node_modules/foo/bar.js` eller `.env`) i den andre, og verktøyet evaluerer hver bane nøyaktig slik git ville gjort: kommentarer og tomme linjer hoppes over, med mindre en ledende mellomrom blir fjernet, med mindre en ledende regel blir fjernet. `/` forankrer det til roten i stedet for å la det matche på hvilken som helst dybde, et etterfølgende `/` begrenser det til kataloger, og `*`, `?`, `[abc]` karakterklasser og `**` (matching på tvers av kataloggrenser) fungerer alle i henhold til de dokumenterte glob-reglene.
Kritisk er det at stier sjekkes katalog for katalog fra roten og ned, på samme måte som gits egen ignoreringsmotor fungerer - ikke ved å teste hele banen mot hver regel isolert. Det er det som gjør det mulig å oppdage død-negeringstilfellet riktig: hvis `dist/` ignoreres på linje 3 og en senere `!dist/keep.js` prøver å redde én fil inne i den, rapporterer dette verktøyet `dist/keep.js` som fortsatt ignorert, navngir line-3-regelen som årsak, og silent flagger separat i stedet for shadowed i stedet for shadowed negasjonen.
Resultattabellen gir hver testet bane sin egen rad med en klar ja/nei ignorert dom, den eksakte regelteksten og linjenummeret som avgjorde det, og – når det er relevant – et vanlig språknotat som forklarer en skyggefull negasjon eller en arvet overordnet katalogregel. Det er detaljen som gjør en forvirrende .gitignore til en du faktisk kan resonnere om før du forplikter deg.