.gitignore Tester

How to use

1. Paste your .gitignore into the first box, exactly as it is on disk — comments, blank lines, CRLF endings and a byte-order mark are all handled the way git handles them.
2. List the paths you want to test in the second box, one per line, relative to the repository root. End a line with a slash to say that path is a directory: dir-only rules like `logs/` depend on it.
3. Read the table. Each row gives the verdict, the line number that decided and the rule text — the same three facts `git check-ignore -v` prints, plus the excluded parent when there is one.
4. Check the amber panel. It appears when a `!` rule matches a path but cannot take effect because a parent directory is already excluded, which is the usual reason a negation looks right and does nothing.
5. Look at the dead-rule list at the bottom: rules that matched none of the paths you pasted. Against a representative path list, those are the lines worth deleting.

Frequently asked questions

Why does my ! rule not bring the file back?

Because git never looked at the file. When it walks the tree and finds that a directory is excluded, it stops there and does not descend, so no rule about anything inside that directory is ever evaluated — the documentation states it plainly: "It is not possible to re-include a file if a parent directory of that file is excluded." With `logs/` and `!logs/important.log`, the log stays ignored, and this tester shows the decision coming from the directory rule. The fix is to exclude the contents instead of the directory: `logs/*` followed by `!logs/important.log` works, because `logs/*` matches the entries inside logs without excluding logs itself. For a whole subtree the recipe is `/logs/**`, then `!/logs/keep/`, then `!/logs/keep/**`.

What is the difference between build and /build?

A pattern with no slash anywhere in it is matched against the basename of every path, at every depth, so `build` ignores /build, /src/build and /a/b/c/build alike. As soon as the pattern contains a slash that is not its last character, it is anchored to the directory containing the .gitignore, so `/build` and `docs/output` only ever match from the root of that directory downward. This is why a bare `node_modules` in a root .gitignore also hides a nested package's node_modules — usually what people want, but not what they wrote down on purpose. The leading slash is the way to say "only here".

Does logs/ match a file named logs?

No. A trailing slash means the pattern only matches directories, so a plain file called logs is left alone while a directory called logs, at any depth, is ignored together with everything under it. This matters here because a pasted list of paths carries no type information: git decides by looking at the real filesystem, and this tester has to be told. Write `logs/` in the path box for the directory and `logs` for the file — the same string with and without the slash can get opposite verdicts, and that is not a quirk of the tool but the reason `git check-ignore` sometimes disagrees with what people expect when the path does not exist yet.

What do the three forms of ** actually mean?

A `**` only has special meaning when it occupies a whole path segment. `**/foo` at the start matches foo at any depth, and is the explicit form of what a slashless pattern already does. A trailing `foo/**` matches everything inside foo — but not foo itself, which is exactly why the re-include recipe above works. And `a/**/b` in the middle matches a/b, a/x/b and a/x/y/b, zero or more directories included. Anywhere else, the stars are ordinary: `a**b` is just `a*b`, and a single `*` never crosses a slash, so `src/*.c` matches src/main.c but not src/lib/main.c.

The rule looks right, but git still shows my file as modified.

.gitignore only ever applies to files git is not already tracking. Once a file has been committed, adding a pattern for it changes nothing: git keeps reporting its changes and keeps committing them. Untrack it first with `git rm --cached path` (which leaves the working copy in place) and commit that removal; from the next commit on, the ignore rule governs. This tester answers the untracked-file question — the one `check-ignore` answers — so a path it calls ignored can still show up in `git status` if it is in the index, and that is the first thing to check when the two disagree.

Which .gitignore wins when there are several?

Git reads several sources in a fixed order and the more specific one wins: patterns from the command line, then .gitignore files, with a file in a deeper directory overriding one above it, then .git/info/exclude for repository-local rules that are not shared, and finally the global file named by core.excludesFile. Within one file the last matching line decides. This tester models a single .gitignore, so if its verdict disagrees with your repository, a nested .gitignore, an info/exclude entry or your global file is the likely culprit — run `git check-ignore -v` there and the source column will name the file.

Related tools