Gitignore-tester
Lim inn .gitignore-reglene dine og en liste med filstier for å se nøyaktig hvilke filer som ignoreres, av hvilken eksakte regel og linje, og hvilke negasjonsregler som er stille døde fordi en overordnet katalog allerede ignoreres.
🔒 Behandles i sin helhet i nettleseren din – ingenting du skriver inn her blir noen gang lastet opp.
Resultat
«Hvorfor virker ikke .gitignore-negasjonen min?» 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 å inkludere en fil på nytt inni 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 gjenskaper gits faktiske .gitignore-matchealgoritme – ikke en tilnærming – nettopp for å kunne fange og forklare den nøyaktige situasjonen, sammen med alle andre mønsterregler git støtter.
Lim inn .gitignore-reglene dine i én boks og en liste med filstier (én per linje, som `dist/index.js`, `node_modules/foo/bar.js` eller `.env`) i den andre, så evaluerer verktøyet hver sti nøyaktig slik git ville gjort: kommentarer og tomme linjer hoppes over, etterfølgende mellomrom fjernes med mindre de er escaped, en innledende `!` negerer en regel, en innledende `/` forankrer den til roten i stedet for å la den matche på alle dybder, en etterfølgende `/` begrenser den til kataloger, og `*`, `?`, `[abc]`-tegnklasser og `**` (som matcher på tvers av kataloggrenser) fungerer alle i henhold til de dokumenterte glob-reglene.
Avgjørende er at stier sjekkes katalog for katalog fra roten og nedover, på samme måte som gits egen ignoreringsmotor fungerer – ikke ved å teste hele stien mot hver regel isolert. Det er dette som gjør det mulig å oppdage den døde negasjonssaken korrekt: hvis `dist/` ignoreres på linje 3 og en senere `!dist/keep.js` prøver å redde én fil inni den, rapporterer dette verktøyet `dist/keep.js` som fortsatt ignorert, navngir linje 3-regelen som årsaken, og flagger separat negasjonen som skyggelagt i stedet for å stille late som om den virket.
Resultattabellen gir hver testede sti sin egen rad med en tydelig ja/nei-ignoreringsdom, den eksakte regelteksten og linjenummeret som avgjorde den, og – når det er relevant – et klarspråksnotat som forklarer en skyggelagt negasjon eller en arvet regel fra en overordnet katalog. Det er detaljnivået som gjør en forvirrende .gitignore til noe du faktisk kan resonnere rundt før du committer.