.gitignore Pattern Tester｜Visualize Which Rule Actually Hits Each Path
Paste your .gitignore rules and a list of file paths, and this tool shows whether each path is Ignored or Kept, along with the exact rule (and line number) that produced the decision. Built so you can sanity-check negation chains like *.log + !important.log, directory-only patterns like node_modules/, and **/ recursive globs before committing a .gitignore edit.
💡 About this tool
A .gitignore file is full of subtle ordering traps: a later rule can silently override an earlier one, a missing trailing slash can match a file you didn't intend, and **/ globs can either match too aggressively or too narrowly depending on what comes after them. Running git check-ignore -v one path at a time is fine when you know which path you're worried about, but it's painful when you've just edited a 50-line .gitignore and want to see all the consequences side-by-side.
This tester takes the whole rule set on the left and a batch of paths on the right, then renders each evaluation in line with the rule that actually decided it. Negated rules are tagged [negated], dir-only rules are matched only against directory-ish paths, and invalid globs are surfaced as a red banner at the top of the results without stopping the other rules from evaluating.
🧐 Frequently Asked Questions
Q. Do you follow the same precedence as git itself?
A. Yes — rules are evaluated top-down, and the last matching rule wins. Putting *.log first and !important.log second keeps important.log; reversing the order ignores it.
Q. How does dir-only (node_modules/) work here?
A. Patterns ending in / only match directory-like paths. A literal file called node_modules (without a trailing slash) won't be matched. Paste a path like node_modules/lodash/index.js and you'll see it ignored under that rule with the matching line shown.
Q. What about **/ glob behavior?
A. **/foo matches foo at any depth, foo/** matches everything under foo/, and a leading **/ is the same as no anchor — these all follow the rules described in gitignore(5). Try **/build/ against a/build/x and a/b/build/y to confirm.
Q. What if my pattern has a regex error?
A. Invalid patterns (mismatched [, malformed escapes) are listed in a red banner at the top of the results. The evaluation continues for the remaining valid rules.
Q. Can I test multiple .gitignore files at once?
A. The tester evaluates one combined rule set. If you have a parent .gitignore and a sub-folder .gitignore, paste them together in top-down order; the bottom (more local) rules naturally win because they're evaluated last.
Q. Why does my path with a leading / not match?
A. Leading / and ./ are normalized away on the path side. To anchor a pattern to the repo root, write the / on the pattern side (e.g. /dist/).
📚 .gitignore pattern facts
The .gitignore file has been part of git since 2005, but the canonical grammar lives in the gitignore(5) man page, not in the README. A few things from that spec catch even experienced devs off guard: once a parent directory is ignored, no !parent/child rule under it will re-include the child. That's why the official github/gitignore repo keeps negative rules close to the rules they're meant to override and never deep inside an ignored folder.
A second trap that comes up on Stack Overflow regularly: the order matters more than people expect because git uses last-match-wins, not first-match-wins. If you copy a template from github/gitignore and append your own rules at the bottom, you can accidentally re-ignore something the template was un-ignoring above. Running your rule set and your sample paths through this tester before committing the change makes the override pattern visible — the result rows tell you the exact line that decided each verdict, so you can spot a misfire without rerunning git check-ignore against every file.